Transaction exchange platform with watchdog microservice

ABSTRACT

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. Microservices on the transaction exchange platform may interact with the transaction objects based on configured workflows associated with the transactions. Processing on the transaction exchange platform may facilitate clearing and settlement of transactions. Some aspects may provide for dynamic and flexible reconfiguration of workflows and/or microservices. Other aspects may provide for data snapshots and workflow tracking, allowing for monitoring, quality control, and auditability of transactions on the transaction exchange platform.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to the following U.S. patent applications,filed on the same day:

-   -   Attorney Docket No. 009033.00124, titled “Transaction Exchange        Platform Having Streaming Transaction Data and Microservices”        and filed Dec. 20, 2019;    -   Attorney Docket No. 009033.00137, titled “Transaction Exchange        Platform Having Configurable Microservices” and filed Dec. 20,        2019;    -   Attorney Docket No. 009033.00135, titled “Transaction Exchange        Platform With Snapshot Microservice” and filed Dec. 20, 2019;        and    -   Attorney Docket No. 009033.00136, titled “Transaction Exchange        Platform With Watchdog Microservice” and filed Dec. 20, 2019.

Each of the related applications is incorporated by reference herein inits entirety for all purposes.

FIELD OF USE

Aspects of the disclosure relate generally to a transaction exchangeplatform. More specifically, aspects of the disclosure may provide fordynamic, reliable, and auditable processing of transactions through useof a streaming data platform.

BACKGROUND

Computer systems and applications have revolutionized the handling oftransactions and greatly accelerated clearing and settlement processes.Software solutions have been created to facilitate processing,validation, and approval of transactions. These systems serve tointerface transaction originators with clearing and settlementoperations, allowing transactions to flow between enterprises andfacilitating the movement of trillions of dollars per year. Yetregulations, security, and risk management processes have grownincreasingly important and detailed, thereby complicating the approvaland settlement of transactions.

Different transaction types may be subject to different approvalworkflows. Payment processing systems may be configured to perform therequired approval steps for each different transaction type. Yet suchpayment processing systems have become incredibly complex, monolithicsoftware services designed to accommodate and enforce the many aspectsof the process of reviewing and approving a transaction for settlement.Although sometimes divided into modules corresponding to differenttransactions, changes to single steps in a given transaction's approvalworkflow may require re-coding, re-compiling, and re-deploying largesoftware components. Additionally, problems with individual steps of theworkflows can grind the whole approval process to a halt.

Aspects described herein may address these and other shortcomingspresent in existing solutions. Novel aspects discussed herein mayimplement a transaction exchange platform using a streaming dataplatform and microservices to provide faster, more dynamic, and morerobust processing and approval of transactions. The novel transactionexchange platform may provide benefits such as improving the flexibilityand reliability of transaction approval and processing systems, whileoffering robust record keeping for transaction audit purposes. The novelplatform may also provide other benefits such as support for legacy andongoing operations, solving for new and changing requirements in today'senvironment, and adapting to future technologies

SUMMARY

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

Aspects described herein may relate to a transaction exchange platformusing a streaming data platform (SDP) and microservices to processtransactions according to review and approval workflows. The transactionexchange platform may receive transactions from origination sources,which may be added to the SDP as transaction objects. Microservices onthe transaction exchange platform may interact with the transactionobjects based on configured workflows associated with the transactions.Processing on the transaction exchange platform may facilitate clearingand settlement of transactions. Some aspects may provide for dynamic andflexible reconfiguration of workflows and/or microservices. Otheraspects may provide for data snapshots and workflow tracking, allowingfor monitoring, quality control, and auditability of transactions on thetransaction exchange platform.

In particular, some aspects may provide a transaction exchange platformimplemented using a SDP and a plurality of microservices to processtransactions. Transaction objects may be pushed to the SDP fromorigination sources via APIs associated with the transaction exchangeplatform. Transaction objects may include transaction details andtransaction metadata. The transaction metadata may include at least anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow may comprise a plurality of processing stepsrequired to approve a given transaction of the transaction type.

Microservices on the transaction exchange platform may poll the SDP toidentify and retrieve transaction objects having a current workflowstage matching a workflow stage associated with the microservice.Transaction objects matching the microservice's assigned workflow stagemay be processed by the microservice for review, approval, and/or anyother suitable processing as part of the overall series of stepsrequired to approve a transaction of the corresponding transaction type.Processing may result in updating one or more elements of thetransaction metadata. Once the microservice completes its processing ofthe transaction object, the microservice can put the transaction objectback to the SDP with an updated current workflow stage indicating thatthe microservice completed its processing. The updated transactionobject may then be identified and processed by a next microservice basedon the workflow.

The steps of the workflow corresponding to a given transaction type maybe organized as a directed acyclic graph (DAG). The DAG may indicate thesteps required to approve a transaction, from when it enters thetransaction exchange platform until approval is completed and thetransaction is ready for further processing by downstream systems. TheDAG may include parallel paths, whereby the transaction object may besubject to concurrent processing by multiple microservices. The DAG mayindicate pre-requisite conditions that govern the progression of thetransaction object through the stages of the workflow. For example,processing by a microservice in the DAG may be conditioned on thecompletion of processing by one or more other microservices. The DAG mayalso indicate branching, conditional paths where a transaction objectmay be subject to processing by different microservices (and/ordifferent processing generally) based on certain transaction attributes.

A current workflow stage value may be maintained as part of thetransaction metadata in each transaction object. The current workflowstage may indicate which processing steps of the associated workflowhave been completed on the transaction. The current workflow stage mayindicate the completion of status of each respective step of theworkflow. As such, in an example implementation the current workflowstage value may be a set of values and/or a data structure indicatingthe completion of individual workflow steps, e.g. processing byrespective microservices. Microservices may be configured to poll theSDP for transactions having a current workflow stage value thatindicates completion of each of the pre-requisite steps for processingby the microservice.

When the current workflow stage of a transaction object indicates it hascompleted the steps of the corresponding workflow, the transactionobject may be removed from the SDP and routed or otherwise madeavailable to other components of an overall transaction system. Forexample, the approved transaction object, having passed through allsteps of the corresponding workflow, may be published to a publicstreaming data platform accessible outside of the transaction exchangeplatform. Enterprise systems, applications, users, and others may accessthe completed transaction objects on the public streaming data platformand further process for transaction settlement or other purposes.

Some aspects described herein may provide for dynamic reconfiguration ofthe workflows and/or microservices. For example, a workflow may bemodified to change a progression of a transaction object from onemicroservice to the next. This may be implemented by modifying theconfiguration of a microservice to look for a different current workflowstage on the streaming data platform. A microservice may be modified tochange processing logic and/or any other aspect controlling how themicroservice interacts with the streaming data platform and/ortransaction objects, or any other aspect of the microservice. Forexample, processing logic of the microservice may be changed to anupdated version to be used in processing future transactions. Aconfiguration interface may generate configuration transaction objectsthat cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. A configurationtransaction object may be configured such that, when processed by amicroservice, it causes reconfiguration of that microservice.

Reconfiguration of the workflows and/or microservices may be handled ina versioned manner, such that transactions on the SDP may be handledaccording to an appropriate and auditable version of the workflow. Whena new configuration version is pushed to the SDP for a given workflow,it may be added with a new version value. Transaction objects on thetransaction exchange platform may include, as part of their transactionmetadata, an indication of a current version value for the workflow atthe time they entered the transaction exchange platform. Themicroservices on the transaction exchange platform may be furtherconfigured to identify transaction objects having an appropriate currentworkflow stages based on the version value of the transaction object.Thus, transactions added under a first workflow version may reliably beprocessed under the first workflow version, while transactions addedafter a shift to a second workflow version may be processed using thenew, updated workflow version (and associated microservices andprocessing logic).

Some aspects described herein may provide a snapshot microservice on thetransaction exchange platform, configured to maintain a record of thedata values of the transaction object as it progresses through theworkflow. The snapshot microservice may be configured to identify andretrieve transaction objects added to the SDP in an initializationstage. The snapshot microservice may create a snapshot record for newtransaction objects and store a copy of the data of the transactionobject. As the transaction object progresses through the workflow and isprocessed by the other microservices, the snapshot microservice canidentify transaction objects that have their data changed. The snapshotmicroservice can retrieve the changed objects and store snapshot datatracking the change of the transaction object.

These snapshots of the transaction object may be used to correctprocessing errors in the approval workflow, as a transaction object mayhave its data reverted back to an earlier state and its workflow stagereverted to an earlier stage. In this way, the transaction object may bemade to repeat an earlier step of the workflow and be subject tore-processing by a corresponding microservice. The snapshot data mayalso support audit of the transactions, offering a complete picture ofhow the transaction object changed while on the transaction exchangeplatform. The snapshot microservice may track a number of times that atransaction object is reverted/replayed on one or more microservices,and may flag a transaction as presenting problems requiring manual orother review when the number of replays exceeds a transaction or basedon other criteria.

Other aspects described herein may provide a watchdog microservice onthe transaction exchange platform, configured to track the progress oftransaction objects through their respective workflows. The watchdogmicroservice may determine that a transaction object has completed theapproval workflow based on the transaction object completing eachcomponent step of the workflow, and may cause the completed transactionto be output from the transaction exchange platform. The watchdogmicroservice may also enforce the workflow, causing transactions torepeat and/or revisit problematic steps of the workflow. Working inconjunction with the snapshot microservice, the watchdog microservicemay cause a transaction to repeat a step of the workflow by revertingthe transaction object to an earlier state in response to detectingproblems.

According to some aspects, the watchdog microservice may track metricsand/or other statistics associated with the workflows, microservices,and/or transactions. Based on the tracked workflow data, the watchdogmicroservice may be able to assess trends associated with a workflow,microservice, or transaction. The watchdog microservice may compare ametric and/or other statistic to threshold performance values todetermine when the workflow, microservice, or transaction is subject toabnormal or undesirable performance complications. For example, thewatchdog microservice could determine that a particular microservice hasa current average processing time greater than a configured warningthreshold, or outside a typical range. Based on detecting abnormal orundesirable performance of the workflow, microservice, or transaction,the watchdog microservice can generate and/or implement a recommendedcorrective action.

Many corrective actions may be recommended by the watchdog microservice,which may flexibly adapt and learn suitable processes for responding toabnormal system conditions. One recommended corrective action may be tocommand replay of an earlier workflow stage for a transaction or groupof transactions. Working with the snapshot microservice, the watchdogmicroservice can cause a transaction object to revert to an earlierstate, where the reversion to the current workflow stage of thetransaction object would cause it to be processed again by anappropriate microservice. Where a particular microservice is showingperformance abnormalities across a range of transactions, the watchdogmicroservice may determine that the particular microservice is havingproblems and recommend a suitable corrective action. As an example, thewatchdog microservice may determine that a dynamic reconfiguration toimplement alternate processing workflows, addressing the issuespresented by the particular microservice, represents a suitablecorrective action. The watchdog microservice may coordinate with theconfiguration interface to effect a reconfiguration of the workflow andthe corresponding microservices, potentially temporarily. In someimplementations, dynamic reconfiguration of a workflow, microservice, ortransaction may be recommended and implemented once successive replaysthrough the snapshot microservice have failed.

Corresponding apparatus, systems, and computer-readable media are alsowithin the scope of the disclosure.

These features, along with many others, are discussed in greater detailbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 depicts an example of a computing device that may be used inimplementing one or more aspects of the disclosure in accordance withone or more illustrative aspects discussed herein;

FIG. 2 depicts an example operating environment used to discussillustrative aspects of a transaction exchange according to one or moreaspects of the disclosure;

FIG. 3A depicts an example transaction exchange platform according toone or more aspects of the disclosure;

FIGS. 3B-3C depict example structures for microservices according to oneor more aspects of the disclosure;

FIG. 4 depicts an illustrative workflow as a directed acyclic graphaccording to one or more aspects of the disclosure;

FIG. 5 depicts an illustrative method for processing transactions on astreaming data platform according to one or more aspects of thedisclosure;

FIG. 6 depicts an example transaction exchange platform having aconfiguration interface according to one or more aspects of thedisclosure;

FIGS. 7A-7C depict illustrative changes to workflows, as graphs,according to one or more aspects of the disclosure;

FIG. 8 depicts an illustrative method for reconfiguring microservicesaccording to one or more aspects of the disclosure;

FIG. 9 depicts an example transaction exchange platform having asnapshot microservice and a watchdog microservice according to one ormore aspects of the disclosure; and

FIGS. 10-15 depict illustrative methods for operation of the snapshotmicroservice and the watchdog microservice according to one or moreaspects of the disclosure.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings, which form a part hereof, and inwhich is shown by way of illustration various embodiments in whichaspects of the disclosure may be practiced. It is to be understood thatother embodiments may be utilized and structural and functionalmodifications may be made without departing from the scope of thepresent disclosure. Aspects of the disclosure are capable of otherembodiments and of being practiced or being carried out in various ways.Also, it is to be understood that the phraseology and terminology usedherein are for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof.

By way of introduction, aspects described herein may relate to atransaction exchange platform using a streaming data platform andmicroservices to process transactions according to review and approvalworkflows. A transaction exchange platform, according to one or moreaspects discussed herein, may provide a version agnostic data streaming,reactive microservice solution that facilitates payment relatedworkflows to be executed. Although the term “microservice” is usedthroughout this disclosure, aspects are not limited to “microservices”as used in cloud computing contexts. Generally, as used herein“microservice” may refer to a technology process that does work on anobject on a streaming data platform in any given step of a workflow.Aspects discussed herein may refer to “approval” of transactions. Thisgenerally refers to the processing necessary to move a transactionthrough the transaction exchange platform from intake to output, anddoes not necessarily mean that the payment exchange platformaffirmatively approves the nature of the transaction. Instead,“approval” as used herein may refer to processing, validating, and/oraffirmatively approving a transaction according to a workflow indicatingthe steps necessary to process a transaction on the platform before itis ready for output to downstream processors. Some aspects may providefor dynamic and flexible reconfiguration of workflows and/ormicroservices. Other aspects may provide for data snapshots and workflowtracking, allowing for monitoring, quality control, and auditability.Each of these aspects may work in concert to provide a flexible, robust,and auditable processing platform for transaction clearing and approval.

Before discussing these concepts in greater detail, however, severalexamples of a computing device that may be used in implementing and/orotherwise providing various aspects of the disclosure will first bediscussed with respect to FIG. 1.

FIG. 1 illustrates one example of a computing device 101 that may beused to implement one or more illustrative aspects discussed herein. Forexample, computing device 101 may, in some embodiments, implement one ormore aspects of the disclosure by reading and/or executing instructionsand performing one or more actions based on the instructions. In someembodiments, computing device 101 may represent, be incorporated in,and/or include various devices such as a desktop computer, a computerserver, a mobile device (e.g., a laptop computer, a tablet computer, asmart phone, any other types of mobile computing devices, and the like),and/or any other type of data processing device.

Computing device 101 may, in some embodiments, operate in a standaloneenvironment. In others, computing device 101 may operate in a networkedenvironment. As shown in FIG. 1, various network nodes 101, 105, 107,and 109 may be interconnected via a network 103, such as the Internet.Other networks may also or alternatively be used, including privateintranets, corporate networks, LANs, wireless networks, personalnetworks (PAN), and the like. Network 103 is for illustration purposesand may be replaced with fewer or additional computer networks. A localarea network (LAN) may have one or more of any known LAN topology andmay use one or more of a variety of different protocols, such asEthernet. Devices 101, 105, 107, 109 and other devices (not shown) maybe connected to one or more of the networks via twisted pair wires,coaxial cable, fiber optics, radio waves or other communication media.

As seen in FIG. 1, computing device 101 may include a processor 111, RAM113, ROM 115, network interface 117, input/output interfaces 119 (e.g.,keyboard, mouse, display, printer, etc.), and memory 121. Processor 111may include one or more computer processing units (CPUs), graphicalprocessing units (GPUs), and/or other processing units such as aprocessor adapted to perform computations associated with machinelearning. I/O 119 may include a variety of interface units and drivesfor reading, writing, displaying, and/or printing data or files. I/O 119may be coupled with a display such as display 120. Memory 121 may storesoftware for configuring computing device 101 into a special purposecomputing device in order to perform one or more of the variousfunctions discussed herein. Memory 121 may store operating systemsoftware 123 for controlling overall operation of computing device 101,transaction exchange platform software 125 for instructing computingdevice 101 to perform aspects discussed herein, machine learningsoftware 127, smart database 129, and other applications 131. Machinelearning software 127 may be incorporated in and may be a part oftransaction exchange platform software 125. In embodiments, computingdevice 101 may include two or more of any and/or all of these components(e.g., two or more processors, two or more memories, etc.) and/or othercomponents and/or subsystems not illustrated here.

Devices 105, 107, 109 may have similar or different architecture asdescribed with respect to computing device 101. Those of skill in theart will appreciate that the functionality of computing device 101 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc. For example,devices 101, 105, 107, 109, and others may operate in concert to provideparallel computing features in support of the operation of control logic125 and/or software 127.

One or more aspects discussed herein may be embodied in computer-usableor readable data and/or computer-executable instructions, such as in oneor more program modules, executed by one or more computers or otherdevices as described herein. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data typeswhen executed by a processor in a computer or other device. The modulesmay be written in a source code programming language that issubsequently compiled for execution, or may be written in a scriptinglanguage such as (but not limited to) HTML or XML. The computerexecutable instructions may be stored on a computer readable medium suchas a hard disk, optical disk, removable storage media, solid statememory, RAM, etc. As will be appreciated by one of skill in the art, thefunctionality of the program modules may be combined or distributed asdesired in various embodiments. In addition, the functionality may beembodied in whole or in part in firmware or hardware equivalents such asintegrated circuits, field programmable gate arrays (FPGA), and thelike. Particular data structures may be used to more effectivelyimplement one or more aspects discussed herein, and such data structuresare contemplated within the scope of computer executable instructionsand computer-usable data described herein. Various aspects discussedherein may be embodied as a method, a computing device, a dataprocessing system, or a computer program product.

Having discussed several examples of computing devices which may be usedto implement some aspects as discussed further below, discussion willnow turn to methods and techniques for implementing a transactionexchange platform.

Transaction Exchange Platform—Processing Streaming Transaction DataUsing Microservices

Aspects described herein may provide a transaction exchange platformimplemented using a streaming data platform (SDP) and a plurality ofmicroservices to process transactions according to workflowscorresponding to different transaction types. Microservices on thetransaction exchange platform may be configured to retrieve transactionshaving a current workflow stage that is assigned to the microservicefrom the SDP. The microservice may perform one or more steps of theapproval/review workflow for the type of transaction, update the statusof the object, and put it back to the SDP. Other microservices, later inthe workflow, may see that the current workflow status of a transactionindicates that earlier pre-requisite processing steps have completed andmay accordingly retrieve the transaction objects and perform theirrespective workflow steps. When the current workflow stage of atransaction indicates that all requisite steps of the workflow have beencompleted, the transaction may be removed from the SDP of thetransaction exchange platform and output to downstream systems forfurther processing.

A high level system 200 for processing transactions, such as payments,is illustrated in FIG. 2. Transaction processing system 200 may broadlyillustrate the flow of transactions from origination source 205 throughto settlement systems 220. Transactions handled by system 200 may takeany suitable form, generally as payment transactions. Example types ofpayment transactions include: wires, automated clearing house (ACH)payments, checks, cashier checks, real-time payments (RTP), creditcards, and/or many other types of payment transactions. Other factorsthat may inform the “type” of a transaction may include whether thetransaction originates domestically or internationally, whether thedestination is domestic or international, an amount of the transaction,the identity of one or more financial entities associated with thetransaction, and the like. For purposes of the discussion herein, atransaction type may be relevant primarily for informing thereview/approval steps that should be applied to the transaction prior tofinal settlement.

Transactions may begin at origination sources 205. For example, if acustomer were to purchase a donut at a bakery using a credit card, thetransaction may be sent via a point-of-sale (POS) terminal at the bakeryto a payment processor. As another example, an investor may cause a wirepayment to be sent to their broker via a banking website. The bankingwebsite may receive the wire payment transaction and begin the processof facilitating settlement of the wire transaction via a transactionprocessing system 200.

Transactions may be routed to settlement systems 220 to effect thetransfer of the monies indicated in the transaction. For example, thewire transaction may be routed to respective financial institutionsassociated with the investor and broker to indicate the respectivedebit/credit to their accounts. However, substantial review and approvalprocessing may be required before a transaction may be settled. Thisprocessing may involve regulatory, security, and/or risk management.

Transaction exchange platform 210 may serve as an interface between theorigination source 205 and settlement systems 220, and according to someaspects may implement the transaction review and approval workflow foreach supported transaction type. Origination sources 205 may sendtransactions to transaction exchange platform 210 for review andapproval processing, and ultimately for routing to settlement systems220. Transaction exchange platform 210 may be provided by the sameentity operating settlement systems 220 and/or one or more oforigination sources 205, or may be provided by a third-party entity.

Transaction exchange platform 210 may perform the review and approvalprocessing for transactions. This may include interfacing with clearingsystems 215. Clearing systems 215 may provide regulatory, security,and/or risk management support for transactions. For example,transactions may be referred to systems provided by the U.S. FederalReserve as part of a clearance process. As another example, theidentities of the parties to the transaction may need to be evaluatedagainst various criteria in support of anti-money laundering or othersuch efforts. Clearing systems 215 may be provided as part oftransaction exchange platform 210, or as logically separate systems.Clearing systems 215 may be provided by the entities operatingorigination sources 205, transaction exchange platform 210, settlementsystems 220, government entities, and/or other third parties.

Transaction exchange platform 210 may interface with clearing systems215 to complete review and approval processing on the transaction.Transactions that are approved on transaction exchange platform 210 maybe routed to settlement systems 220 for settlement and/or furtherprocessing.

FIG. 3A illustrates a system 300 that may provide further details of anovel transaction exchange platform 320 than provided in FIG. 2,according to some aspects described herein. Similarly, transactions mayoriginate at transaction origination sources 303 and route to downstreamsettlement systems, illustrated in FIG. 3A as enterprise systems andusers 350.

Transaction exchange platform 320 may serve to perform review andapproval workflow processing on transactions received from transactionorigination sources 303 via enterprise transaction intermediary services305. Transaction origination sources 303 may include both first- andthird-party sources of transactions. The enterprise providingtransaction exchange platform 320 may provide transaction intermediaryservices 305 to receive transactions, whether from third-parties or not,and route those transactions to transaction exchange platform 320.Enterprise transaction intermediary service 305 may perform validation,pre-processing, standardization, and/or any other suitable processing toprepare transactions for further handling by transaction exchangeplatform 320.

Transactions may be sent to transaction exchange platform 320 viaapplication programming interfaces (APIs), such as API 311 and API 313.The APIs may validate aspects of the transaction details, and maypackage and/or standardize transactions into transaction objectssuitable for processing on transaction exchange platform 320. In someimplementations, transaction exchange platform 320 may provide differentAPIs for each type of transaction. For example, API 311 may correspondto ACH transactions while API 313 corresponds to wire transactions. Insome implementations, fewer APIs (such as a single centralized API) maybe used to flexibly validate and initialize transactions for processingby transaction exchange platform 320. The APIs for interfacing withtransaction exchange platform 320 may comprise a number of components,such as a public API front-end, basic input validation logic, messagelevel integrity processes, monitoring, and/or integration aspects.

Transaction objects may be pushed to a streaming data platform (SDP) 325underlying transaction exchange platform 320. Streaming data platforms,such as those based on the Apache Kafka open-source platform, may beused to process real-time data in computer systems. Message objectspushed to the streaming data platform may be read by consumer softwaremodules, processed, and put back to the streaming data platform.Transaction objects on SDP 325 may be subject to processing bymicroservices on transaction exchange platform 320, such as microservice331, microservice 332, and microservice 333. The microservices can readand write transaction objects from/to SDP 325. Objects on SDP 325 mayproceed logically through time, e.g. t₀ through t_(n), as they progressthrough stages of the workflow associated with a correspondingtransaction type.

Transaction objects, such as transaction object 307, may includetransaction details, addenda, and transaction metadata. The transactiondetails and/or addenda may include the particulars of the transaction,such as the parties and/or accounts involved, as well as the amount ofthe payment. Addenda data of the transaction object may include, e.g.,ABA routing numbers and other details that may be added, updated, and/orprocessed by the microservices on transaction exchange platform 320. Thetransaction metadata may include at least an indication of a workflowcorresponding to a transaction type of the transaction object and acurrent workflow stage of the transaction object. In someimplementations, discussed further herein, the transaction metadata mayalso include workflow version information.

As an example, transaction object 307 may include the following:

  {  transaction ID : a SHA256 encoded token  workflow type : ACH current workflow stage : init  transaction details : ISO20022 token addenda data { ABA routing : xyz } }

Transaction object 307 may encapsulate any suitable standard paymentobject, such as one storing transaction details in a recognized JSONformat. As mentioned, and as illustrated further in FIG. 6, transactionobjects may also include a current workflow version assigned to thetransaction object. Still other metadata may be included, such as areplay tracking count indicating the number of times that thetransaction has been subject to replay through one or more steps of theworkflow. Transaction details may be immutable, not subject to changewhile the transaction object is on the streaming data platform, whereasmetadata and/or addenda data may be subject to change through additions,removals, updates, and/or other processing or modification by themicroservices on transaction exchange platform 320.

A current workflow stage value may be maintained as part of thetransaction metadata in each transaction object. The current workflowstage may indicate which processing steps of the associated workflowhave been completed on the transaction. The current workflow stage mayindicate the completion status of each respective step of the workflow.As such, in an example implementation the current workflow stage valuemay be a set of values and/or a data structure indicating the completionof individual workflow steps, e.g. processing by respectivemicroservices. Microservices may be configured to poll the SDP fortransactions having a current workflow stage value that indicatescompletion of each of the pre-requisite steps for processing by themicroservice.

Microservices on the transaction exchange platform may poll the SDP toidentify and retrieve transaction objects having a current workflowstage matching a workflow stage associated with the microservice.Transaction objects matching the microservice's assigned workflow stagemay be processed by the microservice for review, approval, and/or anyother suitable processing as part of the overall series of stepsrequired to approve a transaction of the corresponding transaction type.Processing may result in updating one or more elements of thetransaction metadata. Once the microservice completes its processing ofthe transaction object, the microservice can put the transaction objectback to the SDP with an updated current workflow stage indicating thatthe microservice completed its processing. The updated transactionobject may then be identified and processed by a next microservice basedon the workflow.

Turning briefly to FIGS. 3B and 3C, FIG. 3B illustrates an examplestructure for a microservice 330N. The microservice may comprisesubcomponents configured to work in concert to apply processing logicassociated with a workflow step assigned to the microservice. In theillustrated structure, microservice 330N comprises a stream listener3301 which may operate as a standardized way to read from SDP 325 andconsume transaction objects that meet the workflow criteria (e.g.,stage) associated with microservice 330N. Microservice 330N may alsoinclude private API 3302, which may be a RESTful implementation used insynchronous calls supporting singleton integrations into transactionexchange platform 320, and its use may allow only the response to beexposed to the public API aspect of microservice 330N. Microservice 330Nmay also include core logic 3303, which may contain the business logicand associated computer instructions to fulfill microservice 330N'sassigned role in the workflow. Core logic 3303 may be adapted to processtransaction objects in accordance with one or more steps of regulatory,security, and/or risk management processes. Microservice 330N mayfurther include transient data 3304, which may include a data managementlayer that deals with data that is attributed to the local functionalityof the system, for example truth tables used in processing by core logic3303, and persistent data 3307, which may include a construct to capturestate data for the associated workflow stage. Microservice 330N mayfurther include messaging components 3305 to track message levelintegrity via natural key encryption derivations of the payment object.And microservice 330N may include monitoring components 3306, configuredto provide oversight and tracking, and integration components 3308,configured to provide the ability to integrate with software structurepatterns such as Async SDP, SOAP, RESTful API, and the like. Asillustrated in FIG. 3C, however, a microservice may be made up of acollection of other microservices. For example, as illustratedmicroservice 331N comprises component microservices 3321, 3322, and3323.

Returning to FIG. 3A, illustrative transaction exchange platform 320includes three microservices (microservices 331, 332, and 333)configured to operate on ACH transactions. Transaction object 307 is anexample ACH transaction, and is added to SDP 325 via API 311.Transaction object 307 may be added to SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice, or may be commensurate in scope with a firstworkflow stage associated with a first microservice of the workflow. Insome implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 or otherwisehandled alongside workflow processing by the respective microservices.

Walking through the example, transaction object 307 may be added to SDP325 in the initialization stage (stage ‘0’). Microservice 331 may beconfigured to perform a first step in an approval workflow fortransaction having a transaction type of ACH. For example, microservice331 may be configured to verify that the recipient account of the ACHtransaction is valid. Microservice 331 may look for transaction objectson SDP 325 having a first workflow stage (stage ‘1’), for example astage that indicates initialization pre-processing was completed or, insome implementations, transaction objects in the initialization stageitself. As mentioned above, the current workflow stage of transactionobject 307 may indicate each (and/or a subset) of the workflow stepsthat have been completed on transaction object 307, and the currentworkflow stage thus may comprise a data structure listing the completionstatus of each (and/or a subset) of the workflow steps. Microservice 331may poll SDP 325 to retrieve transaction objects having a currentworkflow stage matching (e.g., meeting) the first workflow stageassigned to microservice 331. In this manner, microservice 331 mayextract transaction objects from SDP 325 that have met the criteria formicroservice 331 to begin processing. For example, microservice 331 maybe configured to wait until initialization steps such as new objectsnapshotting is completed before performing its processing to verify therecipient account. Transaction objects retrieved by microservice 331 maybe removed and/or otherwise blocked on SDP 325 pending processing bymicroservice 331.

Microservice 331, having retrieved one or more transaction objects suchas transaction object 307, may perform its corresponding workflow stepon the transaction object. The workflow step may comprise suitableprocessing of the transaction object, such as according to core logic ofmicroservice 331 (similar to core logic 3303 of FIG. 3B). Processing ofthe transaction object by microservice 331 (or any other microservice)may comprise any of: retrieving the transaction object; reviewing valuesand other characteristics of the transaction object; interfacing withclearing systems such as clearing systems 215 and/or other systems;comparing values or characteristics to rules, regulations, policies, andthe like; adding, removing, updating, or otherwise changing any aspectof the transaction addenda data or transaction metadata; generatingreports and/or alerts; presenting the transaction for manual or otherreview; and/or any other suitable processing associated with therespective step of the workflow for transactions of that type. Forexample, processing by a microservice may comprise verifying a value ofthe transaction details, addenda data, and/or transaction metadataagainst at least one rule. As another example, processing may compriseverifying a value of the transaction details, addenda data, and/ortransaction metadata against a watchlist. Processing may comprisedetermining that the transaction details, addenda data, and/ortransaction metadata fail at least one rule; flagging the transactionobject for further review; and holding the transaction object in thecurrent workflow stage pending the further review, where updating thecurrent workflow stage of the transaction object to the third workflowstage is based on determining that the further review is completed.Flagging the transaction object for further review may comprise flaggingthe transaction object for manual review by a user and/or setting thecurrent workflow stage of the transaction object to a current workflowstage associated with another microservice, other than the microservicethat typically processes transactions after the first microservice.

The processed transaction object may be put back to SDP 325 bymicroservice 331, and the current workflow stage of the transactionobject may be updated to indicate that microservice 331 has completedits processing. For example, transaction object 307 may be updated tohave a current workflow stage of ‘2’ after microservice 331 completesits processing.

Back on the SDP 325, the updated transaction object may be subject tofurther processing by other microservices in like fashion. For example,microservice 332 may correspond to a second step of processing in theworkflow corresponding to ACH transactions, such as a regulatory checkassociated with anti-money laundering efforts. Microservice 332 may beconfigured to look for transaction objects having a second currentworkflow stage, e.g., stage ‘2’, on SDP 325. Microservice 332 can pollSDP 325 to retrieve such transaction objects and process them accordingto its own core logic, similarly to that described above with respect tomicroservice 331. The processed transaction object may be put back tothe SDP 325 with an updated current workflow stage indicating thatprocessing by microservice 332 is completed. Microservice 333 may beconfigured to look for a third current workflow stage, e.g. stage ‘3’,and may process transaction objects similarly. For example, microservice333 could perform processing to obligate a customer's account for thevalue of the transaction.

When the current workflow stage of a transaction object indicates it hascompleted the steps of the corresponding workflow, the transactionobject may be removed from SDP 325 and routed or otherwise madeavailable to other components of the overall transaction system. Forexample, the approved transaction object, having passed through allsteps of the corresponding workflow, may be published to a publicstreaming data platform 340 accessible outside of the transactionexchange platform. Enterprise systems, applications, users, and others(e.g. enterprise services and users 350) may access the completedtransaction objects on the public streaming data platform and furtherprocess for transaction settlement or other purposes.

The structure described herein, where microservices poll SDP 325 fortransaction objects having corresponding current workflow stages, maydrive payments and other transactions through the system and requisitereview and approval workflows. As mentioned, the workflow for a giventransaction type may comprise a plurality of processing steps requiredto approve a given transaction of the transaction type. Workflows may beimplemented in the configurations of what workflow stage metadata eachmicroservice is configured to look for on the SDP 325. However,workflows may also be logically described and/or defined using adirected acyclic graph structure, as described further with respect toFIG. 4.

FIG. 4 illustrates a sample directed acyclic graph (DAG) 400 that maycorrespond to a workflow corresponding to transactions having a wiretransaction type. The steps of the workflow corresponding to a giventransaction type may be organized as a DAG. The DAG may comprise nodescorresponding to the individual steps of the workflow, and edgescorresponding to pre-requisite relationships between the steps. The DAGmay indicate how transactions from an origination source such asorigination 410 flow through the transaction exchange platform 320,until approval is completed and the transaction is ready for furtherprocessing by downstream systems. The DAG may include parallel paths,whereby the transaction object may be subject to concurrent processingby multiple microservices. The DAG may indicate pre-requisite conditionsthat govern the progression of the transaction object through the stagesof the workflow. For example, processing by a microservice in the DAGmay be conditioned on the completion of processing by one or more othermicroservices. The DAG may also indicate branching, conditional pathswhere a transaction object may be subject to processing by differentmicroservices (and/or different processing generally) based on certaintransaction attributes.

In the example workflow for wire transactions 400 illustrated in FIG. 4,a transaction object added to transaction platform 320 from origination410 may first enter step ‘A’. Step ‘A’ may correspond to a microservicethat performs processing to verify that a recipient account in thetransaction details and/or addenda is valid. Once step ‘A’ processing iscomplete, the workflow proceeds to step ‘B’, which may correspond to ahigh value thresholder that operates to split transactions for differentprocessing based on their value (also implemented as a microservice).For example, once step ‘A’ is completed and a first microservice updatesthe current workflow stage of the transaction object, a microserviceassociated with step ‘B’ may pick up the transaction object anddetermine if it involves a payment over a certain value, e.g., paymentsmore than $5000. The microservice associated with step ‘B’ may updatethe transaction object with different current workflow stages dependingon whether the transaction should be subject to high value processing(e.g., step ‘C’) or standard processing (e.g., step ‘D’). Step ‘C’ mayoccur subsequent to step ‘B’ determining that a high value transactionshould be subject to enhanced verification, and may comprise performingthe enhanced verification by a corresponding microservice. Step ‘D’ maycomprise performing standard regulatory verification by a correspondingmicroservice. Step ‘D’ may also determine if the transaction is aninternational or domestic wire, and may update the current workflowstage and/or other transaction metadata accordingly. If the transactionis an international wire, it may be routed (by means of the updatedtransaction metadata) to a microservice associated with step ‘E’, whichmay perform further international wire processing. If the transaction isa domestic wire, it may proceed to step ‘F’ once regulatory checks arecompleted. Step ‘F’ may comprise a step to obligate the customer'saccount for the amount of the wire, and may be conditioned on successfulcompletion of steps ‘C’, ‘D’, or ‘E’ depending on how the transactionprogressed through the workflow. For example, a microservicecorresponding to step ‘F’ may be configured to poll SDP 325 fortransactions having a current workflow stage that indicates they havecompleted steps ‘C’, ‘D’, or ‘E’. Finally, completing the workflow step‘G’ may correspond to a microservice configured to send the wiretransaction for settlement, such as to settlement systems 220 of FIG. 2or enterprise services and users 350 of FIG. 3A. Having completedworkflow step ‘G’, the transaction metadata may be updated to indicatecompletion of the workflow. For example, the current workflow stage ofthe transaction object may be updated to indicate completion of step‘G’. As another example, the current workflow stage of the transactionobject may reflect the completion of each of steps ‘A’, ‘B’, ‘D’, ‘F’,and ‘G’.

Workflow 400 is just one example of a workflow corresponding to atransaction type, and the transaction exchange platform 320 may havemany such workflows corresponding to different transaction types.Microservices on transaction exchange platform 320 may be involved inone or more workflows, and may operate on different stages of differentworkflows.

Workflow steps may proceed in parallel, and may be independent of one ormore other steps in the workflow. For example, if validating the accountnumber of the sending party and validating the account number of thereceiving party were handled by different microservices, the workflowmay indicate that both may occur once the transaction is brought ontothe platform. However, later steps may be conditioned on the completionof both steps. Either step may occur first in time, depending on theavailability of each respective microservice to handle the transaction.

Microservices on transaction exchange platform 320 may be automaticallyconfigured to look for a corresponding current workflow stage. Thisautomatic configuration may be based on the DAG structure used tologically define the workflow. For example, the individual microservicesmay be automatically configured to poll SDP 325 for transactions havinga current workflow stage that indicates that the pre-requisite criteriarepresented in the DAG is met prior to processing by the microservice.Each microservice may be configured to look for transaction objects onSDP 325 that have a given workflow type and also have a current workflowstage matching that assigned to the microservice. Thus, microservicesmay be configured to operate as part of multiple workflows, and can lookfor transaction objects at different stages of the workflows. Asdiscussed further herein with respect to FIG. 6, changes to the DAG maybe used to automatically re-configure the microservices to watch fortransaction objects in different workflows and/or different workflowstages.

FIG. 5 depicts a flowchart illustrating an example method 500 to processtransactions by a transaction exchange platform, such as transactionexchange platform 320. Method 500 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 500.

At step 505, the system may configure microservices on the transactionexchange platform to watch for transactions of the streaming dataplatform (SDP) that have transaction metadata indicating that they arein a current workflow stage corresponding to the individualmicroservice. As discussed above with respect to FIG. 4, the system mayautomatically configure the microservices based on a DAG structure thatlogically defines the steps of the workflow and their relationships.

At step 510, the system may receive a transaction object and add it tothe streaming data platform. The transaction object may be received froma transaction origination source such as origination source 303, and maybe received from an enterprise intermediary service, such as enterprisetransaction intermediary service 305. The transaction object may bereceived via one or more APIs of the transaction exchange platform, suchas APIs 311 and 313 of transaction exchange platform 320. Thetransaction object may be added to the SDP in an initialization stage,which may be implemented through setting a current workflow stage of thetransaction object's transaction metadata to an initialization value.The initialization stage may be separate from a first workflow stageassociated with a first microservice of the workflow, or could be thesame as the first workflow stage. Objects in the initialization stagemay be subject to various system processes on the transaction exchangeplatform, such as format or other verifications, standardization,snapshots, and the like. If the initialization stage is separate from afirst workflow stage of the workflow, the transaction object may beupdated to have the first workflow stage once initialization processingis completed.

The transaction object, on the SDP, may be subject to processing by oneor more microservices including first microservice 520 and secondmicroservice 530. First microservice may be configured to poll the SDPfor transactions in a first workflow stage, while second microservicemay be configured to poll the SDP for transactions in a second workflowstage.

At step 521, first microservice 520 may poll the SDP for transactionshaving a particular workflow type (corresponding to a transaction type)and having a first workflow stage within that workflow corresponding tofirst microservice 520. The SDP may identify transaction objects thathave a current workflow stage value that matches the first workflowstage criteria associated with the first microservice 520.Identification of matching transaction may be based on transactionmetadata indicating a type of workflow, a current workflow stage, andother information associated with the workflow (such as workflow versioninformation, discussed below with respect to FIG. 6). At step 523, firstmicroservice 520 may retrieve the matching transaction objects forprocessing. Although steps 521 and 523 are illustrated separately, itwill be understood that in practice they may be part of a singlecontiguous act.

At step 525, first microservice 520 may process the transaction objectsit retrieved from the SDP according to processing logic associated withfirst microservice 520. Processing a transaction object may include:reviewing, assessing, analyzing, updating, adding to, removing, and/orany other suitable processing of the transaction data, addenda data,and/or transaction metadata associated with the transaction object.

At step 527, first microservice 520 may update a current workflow stageof the transaction object to indicate completion of the processingcorresponding to first microservice 520. In some embodiments, thecurrent workflow stage may be updated to different next step valuesdepending on the processing by first microservice 520. For example, asdiscussed with respect to workflow 400 in FIG. 4, a microservice mayupdate the current workflow stage of a transaction object to route it todifferent next microservices depending on whether it meets certaincriteria, such as having a value greater than a threshold amount.

At step 529, first microservice 520 may put the updated transactionobject back to the SDP. The updated transaction object may have one ormore changed values (or none) of its transaction data, addenda data,and/or transaction metadata, in addition to the updated current workflowstage.

In the example of method 500, first microservice 520 may update thecurrent workflow stage of the transaction object to indicate completionof processing by the first microservice 520. This updated currentworkflow stage may correspond to the second current workflow stage thatsecond microservice 530 is looking for on the SDP.

Thus, at step 531, the second microservice 530 may poll the SDP fortransactions having the second workflow stage and, at step 533, mayretrieve transaction objects matching the second workflow stage. Thesecond microservice 530 may perform similar processing to that describedabove with respect to first microservice 520. That is, steps 531, 533,535, 537, and 539 may be analogous to steps 521, 523, 525, 527, and 529,modified as appropriate for the role assigned to second microservice 530in the workflow for a given transaction type. The processed, updatedtransaction object may be put back to the SDP with an updated currentworkflow stage indicating completion of the processing corresponding tosecond microservice 530.

At step 540, the system may determine that the current workflow stagemetadata of the transaction object indicates that all requisiteprocessing steps of the workflow have been completed. As a result,processing by the transaction exchange platform may be completed and theapproved transaction object may be removed from the SDP and output forfurther processing and/or settlement. For example, as illustrated inFIG. 3A, a completed, approved transaction may be output to a public SDPfor access by downstream systems and users.

Thus, according to some embodiments a computer-implemented method methodmay receive a transaction object comprising transaction details andtransaction metadata. That transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The computer-implemented method may furthercomprise adding the transaction object to a streaming data platform andupdating the current workflow stage of the transaction object to a firstworkflow stage. A first microservice may poll the streaming dataplatform to retrieve transactions matching the first workflow stage. Thefirst workflow stage may be associated with the first microservice basedon the workflow corresponding to the transaction type. The firstmicroservice may retrieve, from the streaming data platform, thetransaction object based on the current workflow stage matching thefirst workflow stage. The first microservice may process the transactionobject. The computer-implemented method may further comprise updatingthe current workflow stage of the transaction object to a secondworkflow stage based on completing processing, by the firstmicroservice, of the transaction object. A second microservice may pollthe streaming data platform to retrieve transactions matching the secondworkflow stage. The second workflow stage may be associated with thesecond microservice based on the workflow corresponding to thetransaction type. The second microservice may retrieve, from thestreaming data platform, the transaction object based on the currentworkflow stage matching the second workflow stage. The secondmicroservice may process the transaction object. Thecomputer-implemented method may further comprises updating the currentworkflow stage of the transaction object to a third workflow stage basedon completing processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the plurality ofprocessing steps. A different second workflow may be associated with asecond transaction type and may comprise a different second plurality ofprocessing steps required to approve a given transaction of the secondtransaction type. The second transaction type may be different from thetransaction type. The first microservice may operate on transactionsassociated with both the workflow and the different second workflow. Theplurality of processing steps of the workflow may indicate that thefirst microservice processes the transaction object at a different stagethan the different second plurality of processing steps of the differentsecond workflow.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the DAG. Thecomputer-implemented method may further comprise, responsive to anupdate to at least one of the plurality of processing steps indicated inthe DAG, automatically reconfiguring at least one microservice based onthe update.

The current workflow stage of the transaction object may comprise a datastructure indicating completion status of each respective step of aplurality of processing steps associated with the workflow. Thetransaction object may be updated to have a current workflow stagecorresponding to the second workflow stage based on the current workflowstage indicating that the transaction object has been processed by atleast the first microservice and a different third microservice. Thefirst workflow stage and a fourth workflow stage may be independent,such that a third microservice receives the transaction object based onthe current workflow stage of the transaction object matching the fourthworkflow stage irrespective of whether the first microservice hasprocessed the transaction object.

The transaction details may be immutable and may not change while thetransaction object is on the streaming data platform. The processing, bythe first microservice, of the transaction object may comprise verifyinga value of the transaction details, addenda data, and/or transactionmetadata against at least one rule. Processing of the transaction objectby the first microservice may comprise verifying a value of thetransaction details, addenda data, and/or transaction metadata against awatchlist. Processing of the transaction object by the secondmicroservice may comprise determining that the transaction details,addenda data, and/or transaction metadata fail at least one rule,flagging the transaction object for further review, and holding thetransaction object in the second workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object tothe third workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisesetting the current workflow stage of the transaction object to a fourthworkflow stage associated with a third microservice. Updating thecurrent workflow stage of the transaction object to the third workflowstage may be based on determining that processing by the thirdmicroservice is completed.

As examples, the transaction type of the transaction object may be awire type transaction. The workflow may comprise a plurality ofprocessing steps required to approve a wire transaction. The transactiontype of the transaction object may be an automated clearing house (ACH)type transaction. The workflow may comprise a plurality of processingsteps required to approve an ACH transaction. The transaction type ofthe transaction object may be a cashier check type transaction. Theworkflow may comprise a plurality of processing steps required toapprove a cashier check transaction. The first microservice may processthe transaction object to validate a routing number associated with thetransaction object. The second microservice may process the transactionobject to verify compliance with at least one regulatory requirementassociated with the transaction type. The transaction object may bereceived via an application programming interface (API).

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice and a second microservice. The first andsecond microservice may be automatically configured to watch fortransactions on the streaming data platform in corresponding workflowstages based on a plurality of workflows corresponding to a plurality oftransaction types. The memory may store instructions that, when executedby the at least one processor, cause the platform to receive atransaction object comprising transaction details and transactionmetadata. The transaction metadata may comprise an indication of aworkflow corresponding to a transaction type of the transaction objectand a current workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The instructions, when executed by the at least oneprocessor, may further cause the platform to add the transaction objectto the streaming data platform; update the current workflow stage of thetransaction object to a first workflow stage; and poll, by the firstmicroservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The instructions, when executedby the at least one processor, may further cause the platform toretrieve, by the first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; process, by the first microservice,the transaction object to add, remove, or update addenda data associatedwith the transaction object; update the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; andpoll, by the second microservice, the streaming data platform toretrieve transactions matching the second workflow stage. The secondworkflow stage may be associated with the second microservice based onthe workflow corresponding to the transaction type. The instructions,when executed by the at least one processor, may further cause theplatform to retrieve, by the second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage; process, by the secondmicroservice, the transaction object; update the current workflow stageof the transaction object to a third workflow stage based on completingprocessing, by the second microservice, of the transaction object;determine that the current workflow stage of the transaction objectindicates that the transaction object has completed processingcorresponding to the workflow; and remove the transaction object fromthe streaming data platform and output the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; updating the currentworkflow stage of the transaction object to a first workflow stage; andpolling, by a first microservice, the streaming data platform toretrieve transactions matching the first workflow stage. The firstworkflow stage may be associated with the first microservice based onthe workflow corresponding to the transaction type. The steps mayfurther comprise retrieving, by the first microservice and from thestreaming data platform, the transaction object based on the currentworkflow stage matching the first workflow stage; processing, by thefirst microservice, the transaction object; and polling, by a secondmicroservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may be alsoassociated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the second microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; processing, by the secondmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice and the secondmicroservice, of the transaction object; and polling, by a thirdmicroservice, the streaming data platform to retrieve transactionsmatching the second workflow stage. The second workflow stage may beassociated with the third microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the third microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the second workflow stage; processing, by the thirdmicroservice, the transaction object; updating the current workflowstage of the transaction object to a third workflow stage based oncompleting processing, by the third microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; and retrieving, by a second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage. The second workflow stage maybe associated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the second microservice, the transaction object; updatingthe current workflow stage of the transaction object to a third workflowstage based on completing processing, by the second microservice, of thetransaction object; determining that the current workflow stage of thetransaction object indicates that the transaction object has completedprocessing corresponding to the workflow; and removing the transactionobject from the streaming data platform and outputting the transactionobject and an indication that the transaction object has completed theprocessing corresponding to the workflow.

Configurator—Dynamic Microservice Configuration

One or more aspects described herein may provide for dynamicreconfiguration of the workflows and/or microservices. For example, aworkflow may be modified to change a progression of a transaction objectfrom one microservice to the next. This may be implemented by modifyingthe configuration of a microservice to look for a different currentworkflow stage on the streaming data platform. A microservice may bemodified to change processing logic and/or any other aspect controllinghow the microservice interacts with the streaming data platform and/ortransaction objects, or any other aspect of the microservice. Forexample, processing logic of the microservice may be changed to anupdated version to be used in processing future transactions.

A configuration interface may generate configuration transaction objectsthat cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. The configurationtransaction objects may operate such that a target microservice isreconfigured as a result of processing the configuration transactionobject, whether to look for transactions on a different workflow and/orworkflow stage, or to modify the processing logic applied to thetransactions retrieved by the microservice.

As discussed above, each defined workflow on transaction exchangeplatform 320 may accept a transaction as part of the transaction's“saga” through the transaction exchange platform. Through the workflow,the transaction may or may not undergo different processing steps, whereeach step may be provided by one or many microservices or vendorsystems. In this way, updating the “saga” that applies to themicroservices, integrated vendor systems and datasets, and the entiretransaction exchange ecosystem may be akin to an exercise inconfiguration control. Aspects described herein may allow configurationsto be loaded into the transaction exchange platform via the streamingdata platform, and may be used to update the entire transaction exchangeplatform, one or more components of the transaction exchange platform,and/or transactions on the platform.

Traditional methods for doing this may require that each element of theworkflow be updated, creating exponentially expanding complexity,downtime, and consequently interjecting risk to the transaction exchangeecosystem. Dynamic reconfiguration as described further herein may solvea problem of traditional deployments that interrupt the entire systemand require each component to be individually validated. It may alsointerject a level of control in the deployment by enabling any level ofcontrol from the level of remapping the system up to controlling whichcomponent gets transactions associated with different versions of thecorresponding workflow. Dynamic reconfiguration may also provide controlover the system so that configuration can work from the most tacticalsingle transaction (singleton) level up to the entire transactionexchange. Coupled with other tools, such as cloud-based resiliencytools, dynamic reconfiguration may provide a level of flexibility notpresent in other deployment approaches or solutions to simplifyingand/or mitigating the risk of a failed deployment.

The transaction exchange may exist in a space that includes numerouslegacy, vendor, and future state solutions. Dynamic reconfiguration mayprovide advantages in supporting partnering with vendors and thirdparties of any kind as an integration approach can be agreed on andbrought into the transaction exchange as a service controlled throughdynamic reconfiguration. Once integrated, similarly to the versioncontrol described herein, the integration service can be toggled on andoff easily through dynamic reconfiguration processes.

FIG. 6 illustrates a transaction processing system 600, similar to thatillustrated in FIG. 3A and sharing many like components. However,transaction processing system 600 includes configuration interface 660to provide dynamic reconfiguration of the workflows and/ormicroservices. Configuration interface 660 may push configurationtransaction objects to SDP 325 to cause re-configuration of a firstmicroservice 631 a (represented as first version 631 a, which may beupdated to second version 631 b). Due to dynamic reconfiguration,transaction objects may be modified to keep track of the workflowversion they should be processed under, as shown by example transactionobject 607.

Users managing transaction exchange platform 320 may determine todynamically reconfigure one or more aspects of the platform, such as bymodifying a workflow or causing a new version of a microservice to bedeployed. Reconfiguration may be prompted through other processes, suchas via a watchdog microservice as discussed further below with respectto FIG. 9. Reconfiguration may be done to update and/or improve softwareprocesses. Reconfiguration may also be done to address problems thatarise during processing, such as when certain systems become unavailableor otherwise encounter problems. Reconfiguration may be done as a newpersistent configuration, or could be temporary pending resolution of anissue. The reconfiguration may target any aspect of the platform withdesired granularity. For example, the reconfiguration may apply to theentire platform, one or more microservices, and/or one or moretransactions, as appropriate. Workflows on transaction exchange platform320 may also be reconfigured, which may be accomplished throughmodifying individual microservices to control the workflow type andworkflow stages that they watch for.

Configuration interface 660 may generate configuration transactionobjects that cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. Each microservice ontransaction exchange platform 320 may be configured to watch fortransaction objects having a configuration workflow type (e.g.,configuration transaction objects), and may have a correspondingworkflow stage similarly to that discussed above with respect to FIGS.3A and 4.

A configuration transaction object may be configured such that, whenprocessed by a microservice, it causes reconfiguration of thatmicroservice. Microservices on the transaction exchange platform 320 maybe programmed to process configuration transaction objects and makesuitable changes to their parameters based on the processed objects. Forexample, a microservice may process configuration transaction objectcomprising instructions to update the workflow assigned to themicroservice to a second version of the workflow, e.g., ACH v. 2, andmay update a workflow stage assigned to the microservice.Reconfiguration of microservices can be used to update workflows to newversions, create new workflows, and/or modify existing workflows.Transactions requiring modified processing may be assigned tomodified/updated/other workflows to change their assigned processing.

Versioning may be used to control processing by appropriate workflows,and may facilitate reliable and accurate record keeping and playback. Bytracking which version of a workflow handles a transaction, thetransaction can be replayed using the same version at a later time aspart of an audit. To this end, microservices may maintain separateindications of each workflow and version handled by the microservice.Transactions may maintain transaction metadata indicating a versionvalue for the workflow applied to the transaction. Transactions may beassigned a current workflow value when added to the transaction exchangeplatform, and this may be maintained through the life of thetransaction. In some circumstances, the version may be changed later andthe transaction re-run through the new version of the workflow.

Examples of some types of changes that may be implemented throughdynamic reconfiguration will be discussed with references to FIGS.7A-7C.

FIG. 7A illustrates pushing a new configuration to one or more of themicroservices associated with example workflow 710, which may correspondto example wire transaction workflow 400. This new configuration maymodify the processing logic applied by one or more of the microservicescorresponding to the steps of workflow 400/710. Configuration interface660 may generate a configuration transaction object comprising the newconfiguration and push it to the SDP stream. The configurationtransaction object may cause update of the microservices mid-stream aspart of the flow within the transaction exchange platform on the SDP.Each microservice, as with transaction objects, may be configured towatch for configuration transaction objects associated with aconfiguration workflow and corresponding workflow stage. Themicroservices may retrieve matching configuration transaction objectsand process them to effect an update to their respective processinglogic. A microservice, transaction object, and/or the configurationmicroservice may maintain a new and prior version of theirconfigurations. This may allow for processing under an appropriateversion, and may facilitate a transition between versions as furtherdiscussed herein.

The mid-stream nature of the dynamic reconfiguration may help avoidsignificant interruptions and replayability problems posed by priorsolutions. As illustrated, transactions 20, 30, 31, 32, and 33 may be onthe SDP and already subject to processing by microservices in thecurrent version of the workflow. When a new configuration is pushed(such as version 6.0), the transactions pending on the SDP may continueto be processed according to the prior version that they started under(e.g., version 5.0). New transactions 34, 35, 36, and 37 may beprocessed under the new version (6.0). As described above, this may beeffected through transaction metadata tracking the workflow versionassociated with the transaction as well as by configuring themicroservices to utilize version metadata in retrieving transactionsfrom the SDP. For example, returning to FIG. 6, microservice 631 a mayrepresent a first version of a microservice that looks for transactionsin a given workflow type that have a first version value at acorresponding first workflow stage. Microservice 631 b may represent asecond version of the microservice, and may look for transactions in thesame workflow type but having a second version value at the samecorresponding first workflow stage. In some implementations, the versionvalue may be combined with the workflow type rather than separate (e.g.,“ACHv1” and “ACHv2” as separate workflows rather than version values).

This procedure, pushing configuration transaction objects via the SDP,may provide additional advantages in that, when new components areadded, the configuration interface 660 can interject that new componentmid-stream so that it is enabled as a new route without updating theentire transaction exchange. This limits disruption to the local “new”component being added or changed while protecting the entire system forthe change. This may be advantageous as change remains one of the singlebiggest drivers of break events. It also enables on-the-fly updateswithout taking the entire system down into maintenance.

FIG. 7B illustrates a dynamic reconfiguration of a workflow process 720,such as when a component becomes unavailable due to breakage or otheradverse events. The dynamic reconfiguration may reconfigure the workflowto bypass problematic services and redirect the workflow to manualreview and/or other replacement processing steps. The reconfigurationmay avoid bottlenecks associated with microservices earlier in theworkflow breaking and preventing transactions from advancing to latermicroservices. Reconfiguration of workflows may be accomplished throughreconfiguring the microservices involved in the workflow to look fordifferent current workflow stages on the SDP.

For example, in reconfigured workflow process 720, which may be amodification of example wire transaction workflow 400, the dynamicreconfiguration may cause all wire transactions to be subject to theenhanced processing of step ‘C’ rather than the branching pathsdescribed above with respect to FIG. 4. This may be due to enhancedsecurity concerns, problems with international wire processing, problemsat other components, etc. The reconfiguration of FIG. 7B may beaccomplished by configuration interface 660 pushing a configurationtransaction object to the SDP that is configured to cause themicroservices associated with workflow 400/720 to modify what workflowsand workflow stages they look for, as well as how they update thecurrent workflow once processing is completed. In particular, themodification shown in FIG. 7B could be effected by modifying themicroservice associated with step ‘D’ to not pull any transactions,while the microservice affiliated with step ‘C’ may pull alltransactions completed by step ‘B’; or step ‘B’ could be modified toupdate the current workflow of all processed transactions such that theyprogress to the enhanced verification of step ‘C’, for example.

Modifications to the workflow may be done in response to determiningconditions that indicate that modified workflow processing should beimplemented. The modifications may also be done in response to userchanges to a DAG representing the workflow. A user may modify the DAG todefine a new workflow/version and the configuration interface 660 maygenerate a suitable configuration transaction object and push it to theSDP to effect the change. The system may provide a graphical userinterface to facilitate users entering modifications to the DAGassociated with the workflow processing.

Reconfiguration of the workflows and/or microservices may be handled ina versioned manner, such that transactions on the SDP may be handledaccording to an appropriate and auditable version of the workflow. Whena new configuration version is pushed to the SDP for a given workflow,it may be added with a new version value. Transaction objects on thetransaction exchange platform may include, as part of their transactionmetadata, an indication of a current version value for the workflow atthe time they entered the transaction exchange platform. Themicroservices on the transaction exchange platform may be furtherconfigured to identify transaction objects having an appropriate currentworkflow stages based on the version value of the transaction object.Thus, transactions added under a first workflow version may reliably beprocessed under the first workflow version, while transaction addedafter a shift to a second workflow version may be processed using thenew, updated workflow version (and associated microservices andprocessing logic).

Thus, a first microservice in a first version 631 a may be originallyconfigured to watch for transactions associated with the first workflowthat have a first version value, while the first microservice in asecond version 631 b may be configured to watch for transactionsassociated with the first workflow that have a different second versionvalue. Transactions added to the transaction exchange platform may beadded having a first version value prior to reconfiguring the firstmicroservice. The first version of the first microservice 631 a mayretrieve transactions matching the first version value in acorresponding workflow/stage. Once a reconfiguration is pushed to theSDP, later transaction added to the SDP may be added having a secondversion value. The second version of the first microservice 631 b mayretrieve transaction matching the second version value in acorresponding workflow/stage. This may allow for reliable and replayableprocessing of transactions according to the appropriate version ofapproval workflows.

New workflow versions may be added as illustrated in FIG. 7C, throughworkflow 730. One flexible use of this approach is the ability togenerate a workflow designed to modify an individual transaction and/orgroup of transactions. Version 1 of the work flow, indicated by thesingle arrows, may be applied to general transaction objects of a giventransaction type. Version 2 of the workflow, indicated by the doublearrows, may be applied to problematic transactions subject to modifiedprocessing. The transaction exchange platform may support microservices,queuing, and manual workflows as part of being highly resilient,especially around high value workflows. As such, the dynamicconfiguration aspects may facilitate controlling a single transaction'spath through the platform enabling it to bypass steps normally requiredby the common workflow. A new workflow can be introduced to theecosystem with differentiating execution tied directly to a transaction.

As an example implementation, the following sample data illustrates howa workflow may change across versions of the workflow according to oneor more aspects:

Initial Configuration Version 1 {  ″SecurityIdentifier″: ″<<identifier >>″,  ″ConfigurationVersion″: ″1″,  ″WorkflowStage″: [{  ″A″:[{   ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],  ″WorkflowStageCompleted″: [″INIT″]  }],  ″B″: [{   ″WorkflowType″:[″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],   ″WorkflowStageCompleted″:[″A″]  }],  ″C″: [{   ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″, ″CHECK″,″CONFIG″],   ″WorkflowStageCompleted″: [″B″]  }],  ″E″: [{  ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],  ″WorkflowStageCompleted″: [″B″]  }],  ″F″: [{   ″WorkflowType″:[″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],   ″WorkflowStageCompleted″:[″C″, ″E″]  }],  ″G″: [{   ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″,″CHECK″, ″CONFIG″],   ″WorkflowStageCompleted″: [″F″]  }]  }] } PostConfiguration Update Version 2 {  ″SecurityIdentifier″: ″<<identifier >>″,  ″ConfigurationVersion″: ″2″,  ″WorkflowStage″: [{  ″A″: [{    ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],  ″WorkflowStageCompleted″: [″INIT″]  ″B″: [{   ″WorkflowType″: [″WIRE″,″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],   ″WorkflowStageCompleted″: [″A″]  }], ″D″: [{   ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],  ″WorkflowStageCompleted″: [″B″]  }],  ″C″: [{   ″WorkflowType″:[″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″] ,   ″WorkflowStageCompleted″:[″D″]  }],  ″F″: [{   ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″, ″CHECK″,″CONFIG″],   ″WorkflowStageCompleted″: [″C″]  }];  ″G″: [{  ″WorkflowType″: [″WIRE″, ″ACH″, ″RTP″, ″CHECK″, ″CONFIG″],  ″WorkflowStageCompleted″: [″F″]  }]  }] }

Another aspect of dynamic reconfiguration may provide an eventconfiguration library. Configurations employed to process transactionshave certain characteristics may be stored for re-use in other settings,such as when those same characteristics are encountered again.Configurations that were pushed to resolve those transaction may be usedagain to facilitate handling of other similar transactions. For example,if manual or other review identifies a high risk transaction, a highrisk transaction configuration can be pushed to apply a high riskversion of the workflow to the high risk transaction. As a particularexample, consider when a transaction is associated with a merger of twocompanies. To facilitate the merger, transactions may be reconfigured tobypass standard workflows and feed through specialized microservicesconfigured to meet specific reporting needs of M&A transactions.

These configurations may be utilized manually, automatically, through ahybrid approach, and others. For example, machine learning may beemployed to recognize problem situations with transactions. The machinelearning system may flag a transaction to be reconfigured to follow aconfiguration of the configuration library that was previously employedon similar transactions. The system may be designed to self-optimize itsown configurations, employing approaches based on features such asshortest path, fastest time, most secure, guaranteed deliver, or anyother features desirable to customers.

FIG. 8 depicts a flowchart illustrating an example method 800 todynamically reconfigure a transaction exchange platform, such astransaction exchange platform 320. Method 800 may be performed by anysuitable computing device and/or combination of computing devices,referred to as the system implementing method 800.

At step 805, the configuration interface 660 may generate aconfiguration transaction object. The configuration transaction objectmay be configured to cause a reconfiguration of the transaction exchangeplatform, one or more workflows, one or more microservices, and/or oneor more transactions. The configuration interface 660 may receive arequest to generate the configuration transaction object from a userand/or other system processes, such as a watchdog microservice(discussed further below with respect to FIG. 9). The configurationtransaction object may comprise transaction details and transactionmetadata. The transaction metadata may indicate that the transactionobject has a configuration workflow type and a current workflow stage ofthe configuration transaction object. In some embodiments, the workflowtype of the configuration transaction object is a workflow that ismodified by the configuration transaction object, and other aspects ofthe configuration transaction object indicate to a processingmicroservice that it includes an update to the processing of themicroservice. The configuration transaction object may includeinstructions that, when processed by the microservice, cause themicroservice to be reconfigured. Reconfiguration may include modifyingwhich workflow/version/stage the microservice looks for on the SDP,and/or may include modifying the core processing logic employed by themicroservice.

At step 810, the configuration interface 660 may add the configurationtransaction object to the SDP, where it may await processing by firstmicroservice 820 and second microservice 830.

The configuration transaction object may be picked up by firstmicroservice 820 and second microservice 830 in a similar fashion tothat described above with respect to FIG. 5. At steps 821 and 831, firstand second microservices 820 and 830 may poll the SDP to retrievetransactions matching their assigned workflow stages in correspondingworkflow types. The configuration transaction objects may have aconfiguration workflow type, and the microservices may watch for aconfiguration workflow type object having the workflow stagecorresponding to the microservice. At steps 823 and 833, themicroservices may retrieve the configuration transaction object forprocessing.

At steps 825 and 835, the microservices may process the configurationtransaction object when it is in a corresponding workflow stage.Processing the configuration transaction object may cause themicroservice to be updated. For example, the configuration transactionobject may cause the microservice to update what workflow/version/stageit looks for on the SDP. As another example, processing theconfiguration transaction object may cause the microservice to updatethe core processing logic that it applies to transactions.

At steps 827 and 837, the microservices may update the current workflowstage of the configuration transaction object and, at steps 829 and 839,the microservices may push the updated configuration object back to theSDP. For example, microservice 820 may update the current workflow stageof the configuration object to indicate that microservice 820 hascompleted processing, and microservice 830 may be configured to look fortransaction objects that have a current workflow stage that indicatesthat microservice 820 completed its processing.

At step 840, the system may determine that the current workflow stage ofthe configuration transaction object indicates that the processingassociated with the configuration workflow has completed, and theconfiguration transaction object may be removed from the SDP.Notification may be provided to an entity that prompted thereconfiguration that it has been implemented, in some embodiments.

Thus, according to some aspects, a computer-implemented method maycomprise configuring a plurality of microservices on a streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and may comprise a plurality of processing stepsrequired to approve a given transaction of the transaction type. Thesteps may further comprise generating a configuration transaction objectthat may be configured to cause reconfiguration of the first workflow bycausing reconfiguration of at least one microservice of the plurality ofmicroservices. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow and acurrent workflow stage of the configuration transaction object. Thesteps may further comprise adding the configuration transaction objectto the streaming data platform and updating the current workflow stageof the configuration transaction object to a first workflow stage. Themethod may comprise polling, by a first microservice of the plurality ofmicroservices, the streaming data platform to retrieve transactionsmatching the first workflow stage; retrieving, by the first microserviceand from the streaming data platform, the configuration transactionobject based on the current workflow stage matching the first workflowstage; processing, by the first microservice, the configurationtransaction object to reconfigure the first microservice; and updatingthe current workflow stage of the configuration transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the configuration transaction object. The method mayalso comprise determining that the current workflow stage of theconfiguration transaction object indicates that the configurationtransaction object has completed processing corresponding to theconfiguration workflow, and removing the configuration transactionobject from the streaming data platform and outputting an indicationthat the configuration transaction object has completed the processingcorresponding to the configuration workflow.

Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to watch for a different second workflow stage.Reconfiguring the first microservice may cause the first microservice toprocess transaction objects at a different stage of the plurality ofprocessing steps of the first workflow. Reconfiguring the firstmicroservice may comprise reconfiguring the first microservice to modifyat least one operation that the first microservice performs ontransaction objects associated with the first workflow. Reconfiguringthe first microservice may cause removal of at least one secondmicroservice from the first workflow. The first microservice may beoriginally configured to update completed transactions with a firstcompleted workflow stage. Reconfiguring the first microservice maycomprise reconfiguring the first microservice to update completedtransactions with a different completed workflow stage. Reconfiguringthe first microservice may cause transaction objects to bypass at leastone second microservice included in the first workflow. The firstmicroservice may be originally configured to watch for transactionsassociated with the first workflow that have a first version value. Thereconfigured first microservice may be configured to watch fortransactions associated with the first workflow that have a differentsecond version value.

The method may further comprise adding a first transaction object havinga first version value to the streaming data platform prior toreconfiguring the first microservice; retrieving, by the firstmicroservice and from the streaming data platform, the first transactionobject based on a current workflow stage of the first transactionmatching the first workflow stage; processing, by the firstmicroservice, the first transaction object based on an originalconfiguration of the first microservice based on the first versionvalue; adding a second transaction object having a different secondversion value to the streaming data platform subsequent to reconfiguringthe first microservice; retrieving, by the first microservice and fromthe streaming data platform, the second transaction object based on acurrent workflow stage of the second transaction matching the firstworkflow stage; and processing, by the first microservice, the secondtransaction object based on the reconfiguration of the firstmicroservice based on the second version value. The steps may furthercomprise adding a first transaction object to the streaming dataplatform; determining a current version of the first workflowimplemented on the streaming data platform; and updating a version valueof the first transaction object based on the current version. The firstmicroservice may process the first transaction object based on anoriginal configuration or a modified configuration based on the versionvalue.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first microservice may be automatically configured to watch fortransactions on the streaming data platform in the first workflow stagebased on the DAG. Generating the configuration transaction object may bein response to an update to at least one of the plurality of processingsteps indicated in the DAG. The steps may further comprise providing agraphical user interface to allow a user to update the at least one ofthe plurality of processing steps indicated in the DAG.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be automatically configured to watch for transactionson the streaming data platform in a corresponding workflow stage basedon a plurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingconfiguring the plurality of microservices on the streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and comprises a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise processing, by a first microservice, transactionobjects on the streaming data platform based on the configuration; andgenerating a configuration transaction object that may be configured tocause reconfiguration of the first workflow by causing reconfigurationof at least one of microservice of the plurality of microservices. Theconfiguration transaction object may comprise transaction metadata thatindicates a configuration workflow and a current workflow stage of theconfiguration transaction object. The steps may further comprise addingthe configuration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to a first workflow stage; polling, by a first microservice ofthe plurality of microservices, the streaming data platform to retrievetransactions matching the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Subsequent to processing the configuration transaction object, the firstmicroservice may process transaction objects on the streaming dataplatform based on the reconfiguration.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise configuring a first microservice on a streaming dataplatform to watch for transactions having a first workflow stageassociated with a first workflow corresponding to a transaction type.The first workflow may comprise a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise configuring a second microservice on the streaming dataplatform to watch for transactions having a second workflow stageassociated with the first workflow; and generating a configurationtransaction object that may be configured to cause reconfiguration ofthe first workflow by causing reconfiguration of the first microserviceand the second microservice. The configuration transaction object maycomprise transaction metadata that indicates a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; updating the current workflowstage of the configuration transaction object to the first workflowstage; polling, by the first microservice, the streaming data platformto retrieve transactions matching the first workflow stage; retrieving,by the first microservice and from the streaming data platform, theconfiguration transaction object based on the current workflow stagematching the first workflow stage; processing, by the firstmicroservice, the configuration transaction object to reconfigure thefirst microservice; updating the current workflow stage of theconfiguration transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the configurationtransaction object; polling, by the second microservice, the streamingdata platform to retrieve transactions matching the second workflowstage; retrieving, by the second microservice and from the streamingdata platform, the configuration transaction object based on the currentworkflow stage matching the second workflow stage; processing, by thesecond microservice, the configuration transaction object to reconfigurethe second microservice; updating the current workflow stage of theconfiguration transaction object to a third workflow stage based oncompleting processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the configurationtransaction object indicates that the configuration transaction objecthas completed processing corresponding to the configuration workflow;and removing the configuration transaction object from the streamingdata platform and outputting an indication that the configurationtransaction object has completed the processing corresponding to theconfiguration workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising configuring a plurality of microservices on a streamingdata platform to watch for transactions having a corresponding workflowstage associated with a first workflow. The first workflow maycorrespond to a transaction type and comprises a plurality of processingsteps required to approve a given transaction of the transaction type.The steps may further comprise generating a configuration transactionobject that may be configured to cause reconfiguration of the firstworkflow by causing reconfiguration of at least one microservice of theplurality of microservices. The configuration transaction object maycomprise transaction metadata that indicates: a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; retrieving, by a firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching a firstworkflow stage associated with the first microservice; processing, bythe first microservice, the configuration transaction object toreconfigure the first microservice; and updating the current workflowstage of the configuration transaction object to a second workflow stagebased on completing processing, by the first microservice, of theconfiguration transaction object.

Chronos—Snapshot Microservice and Transaction Replay

Some aspects described herein may provide a snapshot microservice on thetransaction exchange platform, configured to maintain a record of thedata values of each transaction object as they progress through thecorresponding workflows. “Snapshot,” when used to refer to the snapshotmicroservice, may refer to the functionality of the snapshotmicroservice to track a transaction object's data values and each of itschanged states as an archival service. The snapshot microservice thusmay also be referred to as a payment transaction object changed statearchive, or Chronos. The snapshot microservice may create a snapshotrecord for new transaction objects and store a copy of the data of thetransaction object. As the transaction object progresses through theworkflow and is processed by the other microservices, the snapshotmicroservice can identify transaction objects that have their datachanged. The snapshot microservice can retrieve the changed objects andstore snapshot data tracking the change of the transaction object.

FIG. 9 illustrates a transaction processing system 900 that may besimilar to transaction processing systems 300 and/or 600 of FIGS. 3A and6. Transaction processing system 900 may add, relative to systems 300and 600, snapshot microservice 970 and watchdog microservice 980. Thisdocument section focuses on snapshot microservice 970, while the nextdocument section focuses on watchdog microservice 980.

Snapshot microservice 970 may operate on transaction exchange platform320 to maintain a record of the data values of each transaction objecton the streaming data platform, and may track how the transactionobjects change during processing on the platform. Snapshot data may bestored in snapshot database 975, which may comprise on-disk storagecapable of effectively storing large volumes of data. Snapshotmicroservice 970 and snapshot database 975 may be configured to storedifferential snapshots of a transaction object. Snapshot microservice970 may store an original state of a transaction object when it is addedto the SDP, and may store information indicating each subsequent changeto the transaction object. Snapshot microservice may track data valuesassociated with each of the transaction details, transaction addendadata, and/or transaction metadata. In some embodiments however, thetransaction metadata may be additionally and/or alternatively tracked bywatchdog microservice 980.

The snapshot microservice 970 may be configured to identify and retrievetransaction objects added to SDP 325 in an initialization stage.Transaction objects may be added to the SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice 331, or may be commensurate in scope with a firstworkflow stage associated with a first microservice 331 of the workflow.In some implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 that receivetransactions to be added to the SDP 325, or otherwise handled alongsideworkflow processing by the respective microservices 331, 332, and 333.

Snapshot microservice 970 may store an initial snapshot of a transactionobject in the initialization stage, then update a current workflow stageof the transaction object to indicate that the initialization processinghas completed. This may comprise updating the current workflow stage ofthe transaction object to match a first workflow stage associated withmicroservice 331, which microservice 331 performs the first step of theworkflow. Alternatively, snapshot microservice 970 may treat transactionobjects in the first workflow stage as being subject to initialization(as new objects), and may determine that an initial, new snapshot shouldbe recorded in snapshot database 975.

Snapshot microservice 970 may be configured to poll the SDP to retrieveall transaction objects having changed data. In some embodiments, thismay comprise retrieving all transaction objects and determining whetherthere have been any changes. In other embodiments, it may compriseretrieving specifically the transaction objects that have changed,whether based on determining that the data has changed or merely that aworkflow stage has advanced. Snapshot microservice 970 may determine adifference in the changed transaction object and store snapshotinformation indicating the difference. The snapshot information mayinclude metadata such as an associated timestamp, workflow stage, and/orany other suitable metadata to facilitate audit and potential rollbackof the transaction object and workflow processing.

These snapshots of the transaction object may be used to correctprocessing errors in the approval workflow, as a transaction object mayhave its data reverted back to an earlier state and its workflow stagereverted to an earlier stage. In this way, the transaction object may bemade to repeat an earlier step of the workflow and be subject tore-processing by a corresponding microservice (or, in some cases such asrepeated failures, a human operator). The snapshot microservice 970 mayregenerate a transaction object using the snapshot data corresponding tothe transaction object from an earlier time, prior to a point inprocessing that is subject to the rewind. In effect, snapshotmicroservice 970 may roll back the values of the transaction object toan earlier point in time. Then, the regenerated transaction object maybe put back on SDP 325 and will be picked up for re-processing by theearlier microservice. For example, if an error is determined to haveoccurred during processing of transaction object 307 by firstmicroservice 331, the snapshot microservice 970 may revert transactionobject 307 to state prior to processing by first microservice 331. Thefirst microservice 331 would have updated the stage of the transactionobject 307 to the second workflow stage when processing completed. Thesnapshot microservice 970 may revert the current workflow stage of thetransaction object 307 to the first workflow stage, so that when thetransaction object 307 is pushed back to the SDP 325 it will be pickedup for processing again by the first microservice 331.

A command to replay a transaction may be received by the snapshotmicroservice 970. For example, watchdog microservice 980 may determinethat processing by first microservice 331 completed abnormally, and maycommand snapshot microservice 970 to perform a replay. Other conditionsmay prompt a replay, such as an error state of a microservice or thetransaction exchange platform 320.

The snapshot microservice may track the total number of times that atransaction object is reverted/replayed on one or more microservices,and may flag a transaction as presenting problems requiring manual orother review when the number of replays exceeds a transaction or basedon other criteria. Replaying a transaction may cause update of atransaction replay count associated with the transaction, which may bestored as part of the transaction object's transaction metadata and/oras part of the snapshot information. If a threshold number of replaystake place, for example a configurable maximum of 3 replays at a singlestage of the workflow, the snapshot microservice 970 may flag thetransaction as having failed and/or requiring further review. Themaximum, which may be implemented as a threshold value, may beconfigured by a user and/or may be automatically configured by systemprocesses based on historical data, current system state, and otherperformance metrics. The transaction may be held in a workflow stagecorresponding to the microservice where processing failed, in someinstance. In other instances, a failed transaction may be routed toadditional processing, such as by a different workflow and/or otherparts of the same workflow, where it may be processed by othermicroservices.

When a replay occurs, the snapshot information may continue to track allsubsequent events as well as all events that had occurred already on thetransaction, even if they are subject to rewinding. Thus, the snapshotinformation may support a comparison during troubleshooting to assesswhich parts of the system led to errors in the workflow. Thisinformation may be archived to assist in troubleshooting and audits.Snapshot information related to error processing that is fixed viareplay may be deleted upon successful completion of the re-attempt.

The snapshot data may also support audit of the transactions, offering acomplete picture of how the transaction object changed while on thetransaction exchange platform. If desired as part of auditing results,the snapshot microservice 970 may replay an entire transaction snapshotby snapshot. This may be done in support of an audit or fortroubleshooting and analysis.

FIG. 10 depicts a flowchart illustrating an example method 1000 togenerate snapshot information tracking a transaction object on atransaction exchange platform, such as transaction exchange platform320. Method 1000 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1000.

At step 1005, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1031, snapshot microservice 1030 may store an initial snapshotrecord for new transaction objects on the SDP. For example, snapshotmicroservice 1030 may poll the SDP for transaction objects in theinitialization stage. Alternatively and/or additionally, snapshotmicroservice 1030 may poll SDP for all transaction objects, anddetermine which are new and should be stored as initial snapshotrecords.

At step 1033, snapshot microservice 1030 may update the current workflowstage of the transaction object to indicate completion of initializationprocessing by the snapshot microservice 1030. This may comprise updatingthe current workflow stage of the transaction object to be a workflowstage associated with a workflow microservice 1020. At step 1035,snapshot microservice 1030 may put the transaction object back to theSDP with the updated current workflow stage.

At step 1021, workflow microservice 1020 may poll the SDP fortransactions having a current workflow stage assigned to themicroservice, and at step 1023 the workflow microservice may retrievethe matching transaction objects. At step 1025, workflow microservice1020 may process the transaction objects according to its respectiveprocessing logic, which may include updating, adding, removing, and/orotherwise changing values of the transaction details, addenda data,and/or transaction metadata associated with the transaction object. Atstep 1027, workflow microservice 1020 may update the transactionobject's current workflow stage to indicate completion of processing bymicroservice 1020 and, at step 1029, put the updated transaction objectback to the SDP.

At step 1037, snapshot microservice 1030 may poll the SDP fortransactions and, at step 1039, determine transaction having changeddata. Snapshot microservice 1030, at step 1041, may record snapshot datacorresponding to the changed data as a result of processing by workflowmicroservices 1020. The snapshot microservice 1030 may, at step 1043,put the transaction object back to the SDP for further processing byworkflow microservices 1020.

FIG. 11 depicts a flowchart illustrating an example method 1100 toreplay a transaction (e.g., subject it to reprocessing) using a snapshotmicroservice on a transaction exchange platform, such as transactionexchange platform 320. Method 1100 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1100.

At step 1105, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

The transaction object may be processed by microservice 1120 in steps1121, 1123, 1125, 1127, and 1129 as described herein, for example insimilar fashion to that described with respect to FIG. 10 in steps 1021,1023, 1025, 1027, and 1029.

Snapshot microservice 1130 may record initial and changed snapshotinformation in steps 1131 and 1131, as described in greater detail abovewith respect to FIG. 10 in steps 1031, 1033, 1035, 1037, 1039, 1041, and1043.

At step 1135, snapshot microservice 1130 may receive a command to replaya workflow step for a transaction object. For example, a watchdogmicroservice may send snapshot microservice 1130 a command to replay thetransaction object in a first workflow stage.

At step 1137, snapshot microservice 1130 may use the stored snapshotinformation to rollback the transaction object to its state prior to thepoint of replay. The transaction object may be made to repeat an earlierstep of the workflow and be subject to re-processing by a microserviceto the workflow step indicated to be replayed. The snapshot microservice1130 may regenerate a transaction object using the snapshot datacorresponding to the transaction object from an earlier time, prior to apoint in processing that is subject to the rewind.

At step 1139, snapshot microservice 1130 may put the regeneratedtransaction object back on the SDP. Because the regenerated transactionobject has the earlier workflow stage, it will be picked up forre-processing by the earlier microservice.

Thus, according to some aspects, a computer-implemented method maycomprise steps comprising receiving a transaction object comprisingtransaction details, addenda data, and transaction metadata. Thetransaction metadata may comprise an indication of a workflowcorresponding to a transaction type of the transaction object, and acurrent workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The steps may further comprise adding the transactionobject to a streaming data platform. Adding the transaction object tothe streaming data platform may comprise setting the current workflowstage of the transaction object to an initialization stage. The stepsmay further comprise polling, by a snapshot microservice, the streamingdata platform to retrieve transactions matching the initializationstage. The initialization stage may be associated with the snapshotmicroservice. The steps may further comprise retrieving, by the snapshotmicroservice and from the streaming data platform, the transactionobject based on the current workflow stage matching the initializationstage; storing, by the snapshot microservice, snapshot datacorresponding to the transaction object; and updating the currentworkflow stage of the transaction object to a next workflow stage basedon completing storing, by the snapshot microservice, the snapshot datacorresponding to the transaction object. The method may compriseretrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data. The method may comprise determining, by the snapshotmicroservice and via the streaming data platform, that at least onevalue associated with the addenda data of the transaction object haschanged after the transaction object has left the initialization stage,and storing, by the snapshot microservice, snapshot data correspondingto the changed at least one value associated with the addenda data.

Determining that the at least one value associated with the addenda dataof the transaction object has changed may comprise retrieving, by thesnapshot microservice and from the streaming data platform, thetransaction object. The steps may further comprise determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully, and causing the first microservice to repeatprocessing of the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice. Causing the first microservice torepeat processing of the transaction object may comprise regenerating,by the snapshot microservice, the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice, and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determininga number of times that the transaction object has undergone processingby the first microservice and, in response to determining that thenumber of times that the transaction object has undergone processing bythe first microservice exceeds a threshold value, rejecting thetransaction object as having failed processing associated with the firstmicroservice. The steps may further comprise flagging the transactionobject for further review based on rejecting the transaction and holdingthe transaction object in the first workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object toa second workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisecausing the transaction object to be processed by a third microservice.Updating the current workflow stage of the transaction object to thesecond workflow stage may be based on determining that processing by thethird microservice is completed. The snapshot microservice may recordsecond snapshot data corresponding to the transaction object from priorto causing the first microservice to repeat processing of thetransaction object. The second snapshot data may be maintained despitethe repeat processing of the transaction object.

The steps may further comprise determining, by the snapshot microserviceand via the streaming data platform, that at least one value associatedwith the transaction metadata has changed; retrieving, by the snapshotmicroservice and from the streaming data platform, the transactionobject based on determining that the at least one value has changed; andstoring, by the snapshot microservice, data corresponding to the changedat least one value associated with the transaction metadata. The nextworkflow stage may correspond to the first workflow stage associatedwith the first microservice. The initialization stage may correspond tothe first workflow stage. The snapshot microservice may generate atransaction history for the transaction object. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform. The snapshot microservicemay store snapshot data in an on-disk database.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform. Adding the transactionobject to the streaming data platform may comprise setting the currentworkflow stage of the transaction object to an initialization stage. Thesteps may further comprise polling, by a snapshot microservice, thestreaming data platform to retrieve transactions matching theinitialization stage. The initialization stage may be associated withthe snapshot microservice. The steps may further comprise retrieving, bythe snapshot microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the transaction object, updating thecurrent workflow stage of the transaction object to a next workflowstage based on completing storing, by the snapshot microservice, thesnapshot data corresponding to the transaction object; and retrieving,by a first microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching a firstworkflow stage. The first workflow stage may be associated with thefirst microservice based on the workflow corresponding to thetransaction type. The steps may further comprise processing, by thefirst microservice, the transaction object to modify the addenda data;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data.

The steps may further comprise determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise causing the transaction exchangeplatform to regenerate, by the snapshot microservice, the transactionobject based on the snapshot data corresponding to the transactionobject from prior to the start of the processing by the firstmicroservice; and return the regenerated transaction object to thestreaming data platform. A current workflow stage of the regeneratedtransaction object may be set to the first workflow stage. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform.Adding the transaction object to the streaming data platform maycomprise setting the current workflow stage of the transaction object toan initialization stage. The steps may further comprise polling, by asnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; and storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object,updating the current workflow stage of the transaction object to a nextworkflow stage based on completing storing, by the snapshotmicroservice, the snapshot data corresponding to the transaction object;and retrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data; determining, by the snapshot microservice and via thestreaming data platform, that at least one value associated with theaddenda data of the transaction object has changed after the transactionobject has left the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the changed at least onevalue associated with the addenda data; determining that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise regenerating, by the snapshotmicroservice, the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice; and returning the regeneratedtransaction object to the streaming data platform. A current workflowstage of the regenerated transaction object may be set to the firstworkflow stage.

Arbiter—Watchdog Microservice for Tracking, Monitoring, and Remediation

Some aspects described herein may provide a watchdog microservice on thetransaction exchange platform, configured to track the progress oftransaction objects through their respective workflows. “Watchdog,” whenreferring to the watchdog microservice, may refer to the functionalityof the watchdog microservice to observe and archive the progress oftransaction objects on the transaction exchange platform, and enforcethe associated workflows. Thus the watchdog microservice may also bereferred to an an observability and archive microservice, or Arbiter.The watchdog microservice may determine that a transaction object hascompleted the approval workflow based on the transaction objectcompleting each component step of the workflow, and may cause thecompleted transaction to be output from the transaction exchangeplatform. The watchdog microservice may also enforce the workflow,causing transactions to repeat and/or revisit problematic steps of theworkflow.

The watchdog microservice may track metrics and/or other statisticsassociated with the workflows, microservices, and/or transactions. Basedon the tracked workflow data, the watchdog microservice may be able toassess trends associated with a workflow, microservice, or transaction.The watchdog microservice may compare a metric and/or other statistic tothreshold performance values to determine when the workflow,microservice, or transaction is subject to abnormal or undesirableperformance complications. For example, the watchdog microservice coulddetermine that a particular microservice has a current averageprocessing time greater than a configured warning threshold, or outsidea typical range. Based on detecting abnormal or undesirable performanceof the workflow, microservice, or transaction, the watchdog microservicecan generate and/or implement a recommended corrective action. Examplecorrective actions may include causing a transaction to be replayed viaa snapshot microservice, and causing a workflow to be dynamicallyreconfigured using a configuration interface.

FIG. 9, discussed above with respect to the snapshot microservice, alsodepicts watchdog microservice 980 and watchdog database 985. Watchdogmicroservice 980 may generate workflow tracking records for eachtransaction object on the transaction exchange platform 320, and maystore information indicating whether the transaction object completedeach step of the workflow along with timestamps and other suitablemetadata. The workflow tracking records may be stored in watchdogdatabase 985, which may comprise an in-memory database configured tosupport quick access and retrieval of records while on SDP 325.

The watchdog microservice 980 may serve as the judge (arbiter) indetermining when a transaction object has completed the workflowprocessing steps of its corresponding workflow. This is furtherdescribed with respect to FIG. 12.

FIG. 12 depicts a flowchart illustrating an example method 1200 to trackworkflow progress and determine if a transaction has completed theworkflow on a transaction exchange platform, such as transactionexchange platform 320. Method 1200 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1200.

At step 1205, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1231, watchdog microservice 1230 may store an initial record fornew transaction objects on the SDP. Watchdog microservice 1230 mayidentify new transactions on the SDP, potentially as a result of theinitialization stage, and may generate new workflow tracking records forthe new transaction objects. Watchdog microservice 1230 may poll the SDPto retrieve new transactions as they are added. Additionally and/oralternatively, watchdog microservice 1230 may poll the SDP to retrieveall new transactions and determine which are new, as shown in step 1233.

Workflow microservices 1220 may process transaction objects on the SDPin the manners described above in detail. For example, illustrated steps1221, 1223, 1225, 1227, and 1229 may correspond to steps 1021, 1023,1025, 1027, and 1029 of FIG. 10.

At step 1233, watchdog microservice 1230 may poll the SDP fortransactions and, at step 1235, determine transaction objects having achanged workflow stage. In some embodiments, watchdog microservice 1230may poll all transactions and determine which have changes. In otherembodiments, watchdog microservice 1230 may poll the SDP to requesttransaction that have changed.

At step 1237, watchdog microservice 1230 may record workflow trackingdata corresponding to the change in the workflow stage of thetransaction object. For example, watchdog microservice 1230 may update aworkflow tracking record associated with the transaction object toindicate it completed a workflow stage associated with a workflowmicroservice 1220. The watchdog microservice 1230 may further storeother metadata regarding the updated workflow stage, including atimestamp of the recorded change.

At step 1239, the watchdog microservice 1230 may determine whether thecurrent workflow stage of the transaction object (and/or the workflowtracking data) indicate that the transaction object has met therequisite steps of the workflow associated with the transaction type ofthe transaction objects. For example, the watchdog microservice 1230 mayassess whether the current workflow stage information of the transactionmetadata indicates completion of a series of steps that satisfy thecriteria of the workflow associated with a particular transaction typeof the transaction object.

At step 1241, the watchdog microservice 1230 may determine that theworkflow is not complete, and may proceed to step 1245 where thetransaction object is put back to the SDP after recording the workflowtracking information.

If, at step 1241, the watchdog microservice 1230 determines that theworkflow is complete, processing may proceed to step 1243 where thetransaction object is removed from the SDP of the transaction exchangeplatform and output as completed. For example, the transaction objectmay be updated with an indication that it completed the workflow and isapproved, and may be put to a public SDP 340 accessible to enterprisesystems and users 350.

Additionally and/or alternatively to the workflow completiondeterminations described above, the watchdog microservice 980/1230 mayenforce the individual steps of the workflow. The watchdog microservicemay assess whether a current workflow stage indicates a valid workflowstage under the restrictions of the workflow structure. If the currentworkflow stage of the transaction object is not valid, the watchdogmicroservice may cause the transaction object to be processed by one ormore appropriate microservices associated with the workflow, therebyenforcing the workflow. Working in conjunction with the snapshotmicroservice, the watchdog microservice may cause a transaction torepeat a step of the workflow by reverting the transaction object to anearlier state in response to detecting problems.

According to some aspects, the watchdog microservice may track metricsand/or other statistics associated with the workflows, microservices,and/or transactions. Based on the tracked workflow data, the watchdogmicroservice may be able to assess trends associated with a workflow,microservice, or transaction. The watchdog microservice may compare ametric and/or other statistic to threshold performance values todetermine when the workflow, microservice, or transaction is subject toabnormal or undesirable performance complications. This is describedfurther below with respect to FIG. 13.

FIG. 13 depicts a flowchart illustrating an example method 1300 to trackworkflow progress and recommend corrective action based on performancemetrics on a transaction exchange platform, such as transaction exchangeplatform 320. Examples of performance metrics include, for example, howlong it takes a transaction to complete an associated workflow fromstart to finish. As will be discussed, performance metrics may bemeasured at any suitable level, for example per transaction, per groupof transaction, within a time frame, within a sample, and the like.Method 1300 may be performed by any suitable computing device and/orcombination of computing devices, referred to as the system implementingmethod 1300.

At step 1305, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1310, the watchdog microservice may track progress oftransaction objects on the SDP through the microservices and workflowsassociated with a transaction type of the transaction object, asdescribed above with respect to FIG. 12.

At step 1315, the watchdog microservice may determine one or moreperformance metrics associated with the transaction exchange platform,one or more workflows, one or more microservices, types of transactions,groups of transactions, individual transactions, and/or any suitablegranularity. The watchdog microservice may record how long it takes atransaction to move through its corresponding workflow, frommicroservice to microservice. This time may be recorded against upperand/or lower control limits with a rolling time period. The time periodmay be taken into account and normalized against business cycles (forexample: weekends are different than work days and certain hours of thework day look very different). Other metrics may be considered besidesprocessing time, such as throughput (volume), error rates, approve/denyrates, paths taken in branching workflows, and/or any other suitablemetric.

Metrics may be tracked at any desired level of granularity. For example,the watchdog microservice may track how long transaction take toprogress through the ACH workflow, and may assess whether this is withinhistorical performance ranges. Similarly, the watchdog microservice maytrack how long a particular microservice takes to process transactionsover the last five minutes and determine when this rises above a warninglevel, which may indicate a problem with the microservice. The watchdogmicroservice may determine baseline performance metrics for thetransaction exchange platform, workflows, microservices, and the like.Current metrics may be compared to these baseline metrics to determineand address abnormal performance.

At step 1320, the watchdog microservice may determine at least onerecommended action based on the performance metrics. Many correctiveactions may be recommended by the watchdog microservice, which mayflexibly adapt and learn suitable processes for responding to abnormalsystem conditions. A common recommended corrective action may be tocommand replay of an earlier workflow stage for a transaction or groupof transactions. Working with the snapshot microservice, the watchdogmicroservice can cause a transaction object to revert to an earlierstate, where the reversion to the current workflow stage of thetransaction object would cause it to be processed again by anappropriate microservice. Where a particular microservice is showingperformance abnormalities across a range of transactions, the watchdogmicroservice may determine that the particular microservice is havingproblems and recommend a suitable corrective action. As an example, thewatchdog microservice may determine that a dynamic reconfiguration toimplement alternate processing workflows, addressing the issuespresented by the particular microservice, represents a suitablecorrective action. The watchdog microservice may coordinate with theconfiguration interface to effect a reconfiguration of the workflow andthe corresponding microservices, potentially temporarily. In someimplementations, dynamic reconfiguration of a workflow, microservice, ortransaction may be recommended and implemented once successive replaysthrough the snapshot microservice have failed. Such reconfiguration mayaddress patterns of failure that become apparent from repeat errors fromthe microservices/workflows.

The watchdog microservice may implement other corrective actions aswell. For example, the watchdog microservice may utilize machinelearning techniques to self-optimize the workflows based on any suitablefeature, such as enhancing actions (rather than corrective action),security lockdown against intrusions, speed throughput, prioritizedrouting, restart, and most any other incident, administrative, ormanagement handling. The watchdog microservice provides a usefulinterface and allows machine learning collector agents to be deployed onthe transaction exchange platform to gather system state information foruse in optimizing and managing the transaction exchange platform. Othermetrics in addition to performance, security, resiliency,responsiveness, robustness, visiblity, etc. may be considered by thewatchdog microservice, and the flexibility and comprehensive scope ofthe watchdog microservices may enable powerful management of thetransaction exchange platform.

At step 1325, the watchdog microservice may cause the recommended actionto be implemented. For example, the watchdog microservice may commandthe snapshot microservice to replay a workflow stage for the transactionobject. As another example, the watchdog microservice may command theconfiguration interface to dynamically reconfigure one or more workflowsand/or microservices based on the performance metric.

Subsequent to implementing the corrective action, the watchdogmicroservice may determine that successful processing is completed instep 1330. Or the watchdog microservice may determine that processinghas failed in step 1340, and may output the transaction for furtherreview (manually and/or automatically), and may generate anotherrecommended action, at step 1345.

According to some aspects, and as discussed above, the watchdogmicroservice may recommend as a corrective action replay of an earlierworkflow stage for a transaction or group of transactions. Working withthe snapshot microservice, the watchdog microservice can cause atransaction object to revert to an earlier state, where the reversion tothe current workflow stage of the transaction object would cause it tobe processed again by an appropriate microservice. This is describedfurther below with respect to FIG. 14.

FIG. 14 depicts a flowchart illustrating an example method 1400 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1400 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1400. FIG. 14 may combine aspects of FIGS. 11 and13, as explained further below.

At step 1405, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1421, watchdogmicroservice 1420 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1423, watchdog microservice 1420 may determine that atransaction object should replay a workflow stage. For example, asdiscussed above with respect to FIG. 13, the watchdog microservice maydetermine that a transaction object did not correctly complete theworkflow step and/or that the microservice associated with the step isexperiencing abnormal performance issues. At step 1425, the watchdogmicroservice 1420 may command snapshot microservice 1430 to replay thetransaction object at the earlier workflow stage.

Snapshot microservice 1430 may store snapshot data records fortransaction objects on the SDP in steps 1431 and 1433, as discussedabove in FIGS. 10 and 11. At step 1435, snapshot microservice 1430 mayreceive the command to replay the workflow step for the transactionobject from the watchdog microservice 1420. Snapshot microservice mayrollback the transaction object and reinject it to the SDP at steps 1437and 1439, in the manner described above with respect to FIG. 11.

At step 1441, watchdog microservice 1420 may determine if the replayedworkflow stage was processed successfully. If it processed successful,processing may proceed to step 1443 where the transaction workflowcontinues.

If, at step 1441, watchdog microservice 1420 determines that processingdid not complete successfully, watchdog microservice 1420 may determinewhether a maximum number of rollbacks have been attempted at step 1445.The snapshot microservice 1430 and/or watchdog microservice 1420 maymaintain a counter of the number of rollback/replay attempts. The numberof rollback/replay attempts is less than a configurable threshold, thenprocessing may return to step 1425 where watchdog microservice 1420again commands snapshot microservice 1430 to replay the transaction.

If, at step 1445, watchdog microservice 1420 determines that a maximumnumber of replay attempts have already occurred, then watchdogmicroservice may determine a failure of the transaction to progressthrough the workflow stage at step 1447. At step 1449 the watchdogmicroservice 1420 may determine a further recommended action, such astriggering a dynamic reconfiguration of the work follow. This is shownfurther in FIG. 15.

FIG. 15 depicts a flowchart illustrating an example method 1500 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1500 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1500. FIG. 15 may combine aspects of FIGS. 11-14, asexplained further below.

At step 1505, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1521, watchdogmicroservice 1520 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1522, the watchdog microservice may determine that a transactionobject should have a particular workflow stage replayed, and may orderthe snapshot microservice to replay the transaction as described in FIG.14. Step 1522 may be optional, as watchdog microservice 1520 maydetermine to command dynamic reconfiguration even in the absence of areplayed transaction.

At step 1523, the watchdog microservice may determine that thetransaction exchange platform, one or more workflows, one or moremicroservices, or any other component should be modified. As discussedfurther above with respect to FIG. 13, the watchdog microservice maymake this determination based on tracking one or more performancemetrics associated with the transaction exchange platform and/or any ofits components.

At step 1525, the watchdog microservice 1520 may command theconfiguration interface 1530 to reconfigure one or more microservices(and/or workflows, and/or any other component of the transactionexchange platform).

At step 1531, configuration interface 1530 may receive the command toreconfigure the microservices of the workflow, and may proceed throughsteps 1533 and 1535 to generate a configuration transaction object thatis pushed to the SDP to effect the desired reconfiguration, as describedabove with respect to FIG. 8.

At step 1527, the watchdog microservice 1520 may command the snapshotmicroservice to replay the transaction object using the reconfiguredworkflow, if a particular transaction and/or group of transactions weresubject to erroneous and/or failed processing on the originalconfiguration.

At step 1529, the watchdog microservice 1520 may evaluate performance ofthe reconfigured workflow and continue to evaluate performance metricsassociated with aspects of the transaction exchange platform.

Thus, according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object and updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject. In response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed, the method may comprise: retrieving, bythe watchdog microservice and from the streaming data platform, thetransaction object based on determining that the current workflow stagehas changed and storing, by the watchdog microservice, workflow trackingdata corresponding to the transaction object and the changed currentworkflow stage.

The steps may further comprise determining, by the watchdogmicroservice, that the stored workflow tracking data corresponding tothe transaction object indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type and, inresponse to determining that the stored workflow tracking data indicatesthat the transaction object completed each stage of the workflowcorresponding to the transaction type, removing the transaction objectfrom the streaming data platform and outputting the transaction objectand an indication that the transaction object has completed theprocessing corresponding to the workflow. The current workflow stage ofthe transaction object may comprise a data structure indicatingcompletion status of each respective step of a plurality of processingsteps associated with the workflow. The steps may further comprise, inresponse to the determining that the current workflow stage of thetransaction object has changed, determining, by the watchdogmicroservice, whether the current workflow stage of the transactionobject is valid based on the workflow associated with the transactiontype and, in response to determining that the current workflow stage ofthe transaction object is not valid, causing, by the watchdogmicroservice, the transaction object to be processed by one or moremicroservices associated with the workflow. The watchdog microservicemay store workflow tracking data in an in-memory database. The workflowtracking data may comprise a timestamp and an indication of the changeto the current workflow stage of the transaction object. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one performance metric associatedwith the first microservice. The at least one performance metric maycorrespond to a single transaction object. The at least one performancemetric may correspond to a group of transaction objects over a period oftime. The steps may further comprise determining, by the watchdogmicroservice, that the at least one performance metric associated withthe first microservice fails to satisfy at least one thresholdperformance value; and performing at least one action based ondetermining that the at least one performance metric fails to satisfythe at least one threshold performance value. The steps may furthercomprise determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe workflow.

The steps may further comprise determining, by the watchdogmicroservice, that the at least one performance metric associated withthe workflow fails to satisfy at least one threshold performance value;and performing at least one action based on determining that the atleast one performance metric fails to satisfy the at least one thresholdperformance value. The steps may further comprise determining, by thewatchdog microservice and based on the workflow tracking data, at leastone baseline metric associated with the first microservice. The baselinemetric may correspond to processing performance by the firstmicroservice on a set of transaction objects over a period of time. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with a first transaction object processed by the firstmicroservice; determining that the at least one performance metricassociated with the first transaction object fails to satisfy athreshold relationship to the at least one baseline metric; andgenerating a recommended action to be taken on the first transactionobject. The recommended action may comprise causing the firsttransaction object to be re-processed by the first microservice. Therecommended action may comprise re-routing the first transaction objectto be processed by another microservice. The recommended action maycomprise changing the transaction type of the first transaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice, that the stored workflow tracking datacorresponding to the transaction object indicates that the transactionobject completed each stage of the workflow corresponding to thetransaction type; and in response to determining that the storedworkflow tracking data indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type,removing the transaction object from the streaming data platform andoutput the transaction object and an indication that the transactionobject has completed the processing corresponding to the workflow. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with the first microservice. The steps may further comprisedetermining, by the watchdog microservice, that the at least oneperformance metric associated with the first microservice fails tosatisfy at least one threshold performance value; and generating arecommended action based on determining that the at least oneperformance metric fails to satisfy the at least one thresholdperformance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice; andgenerating a graphic user interface display corresponding to the firstmicroservice and comprising the at least one performance metric.

And according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice.

The steps may further comprise polling, by the snapshot microservice,the streaming data platform to retrieve transactions matching aninitialization stage. Transactions may be added to the streaming dataplatform in the initialization stage. The initialization stage may beassociated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with addenda data of thetransaction object has changed after the transaction object has left theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data. The snapshot microservice may cause the firstmicroservice to repeat processing of the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice. Causing the firstmicroservice to repeat processing of the transaction object may compriseregenerating, by the snapshot microservice, the transaction object basedon snapshot data corresponding to the transaction object from prior tothe start of the processing by the first microservice; and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one performance thresholdvalue. The at least one performance metric may correspond to a singletransaction object. The at least one performance metric may correspondto a group of transaction objects over a period of time. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one baseline metric associated withthe first microservice. The baseline metric may correspond to processingperformance by the first microservice on a set of transaction objectsover a period of time. The steps may further comprise determining, bythe watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with a first transaction objectprocessed by the first microservice. Determining that the processing, bythe first microservice, of the transaction object did not completesuccessfully may be based on determining that the at least oneperformance metric associated with the first transaction object fails tosatisfy a threshold relationship to the at least one baseline metric.The steps may further comprise determining a number of times that thetransaction object has undergone processing by the first microservice;in response to determining that the number of times that the transactionobject has undergone processing by the first microservice exceeds athreshold value, rejecting the transaction object as having failedprocessing associated with the first microservice; and determining acorrective action for the transaction object based on rejecting thetransaction object. The corrective action may comprise re-routing thefirst transaction object to be processed by another microservice. Thecorrective action may comprise changing the transaction type of thetransaction object. The corrective action may comprise changing theindication of the workflow corresponding to the transaction type of thetransaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and polling, by asnapshot microservice, the streaming data platform to retrievetransactions matching an initialization stage. Transactions may be addedto the streaming data platform in the initialization stage. Theinitialization stage may be associated with the snapshot microservice.The steps may further comprise retrieving, by the snapshot microserviceand from the streaming data platform, the transaction object based onthe current workflow stage matching the initialization stage; storing,by the snapshot microservice, snapshot data corresponding to thetransaction object; and processing, by a first microservice, thetransaction object on the streaming data platform based on the currentworkflow stage matching a first workflow stage. The first workflow stagemay be associated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further comprisedetermining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data; updating the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object captured by a snapshot microservice.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform. Thetransaction object may be added to the streaming data platform in aninitialization stage. The steps may further comprise polling, by thesnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object; andprocessing, by the first microservice, the transaction object on thestreaming data platform based on the current workflow stage matching afirst workflow stage. The first workflow stage may be associated withthe first microservice based on the workflow corresponding to thetransaction type. The steps may further comprise determining, by thesnapshot microservice and via the streaming data platform, that at leastone value associated with addenda data of the transaction object haschanged after the transaction object has left the initialization stage;storing, by the snapshot microservice, snapshot data corresponding tothe changed at least one value associated with the addenda data;updating the current workflow stage of the transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the transaction object; and in response to determining,by a watchdog microservice and via the streaming data platform, that thecurrent workflow stage of the transaction object has changed, storingworkflow tracking data corresponding to the transaction object and thechanged current workflow stage; determining, by the watchdogmicroservice, that the processing, by the first microservice, of thetransaction object did not complete successfully; and causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice by: regenerating, by the snapshot microservice,the transaction object based on snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice; and returning the regenerated transaction object tothe streaming data platform. The current workflow stage of theregenerated transaction object may be set to the first workflow stage.The steps may further comprise determining, by the watchdog microserviceand based on the workflow tracking data, at least one baseline metricassociated with the first microservice. The baseline metric maycorrespond to processing performance by the first microservice on a setof transaction objects over a period of time. The steps may furthercomprise determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe first transaction object processed by the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thesingle transaction objects fails to satisfy a threshold relationship tothe at least one baseline metric.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfiguring the first microservice or a relatedsecond microservice based on determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully. The steps may further comprise causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice; and determining that the repeat processing of thetransaction object also did not complete successfully. Reconfiguring thefirst microservice or the related second microservice may be based ondetermining that the repeat processing of the transaction object failed.Reconfiguring the first microservice or a related second microservicemay comprise generating a configuration transaction object that may beconfigured to cause reconfiguration of the first workflow by causingreconfiguration of the first microservice. The configuration transactionobject may comprise transaction metadata that indicates a configurationworkflow and a current workflow stage of the configuration transactionobject. The steps may further comprise adding the configurationtransaction object to the streaming data platform; updating the currentworkflow stage of the configuration transaction object to the firstworkflow stage; retrieving, by the first microservice and from thestreaming data platform, the configuration transaction object based onthe current workflow stage matching the first workflow stage; andprocessing, by the first microservice, the configuration transactionobject to reconfigure the first microservice. Reconfiguring the firstmicroservice or the related second microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice or the related second microservicemay comprise reconfiguring the first microservice to modify at least oneoperation that the first microservice performs on transaction objectsassociated with the workflow. Reconfiguring the first microservice orthe related second microservice may comprise reconfiguring the relatedsecond microservice to cause removal of the first microservice from theworkflow. The second related microservice may be a predecessormicroservice that proceeds the first microservice in the workflow. Thesteps may further comprise determining, by the watchdog microservice, atleast one performance metric associated with the first micro service.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one threshold performancevalue. The steps may further comprise determining, by the watchdogmicroservice and based on the workflow tracking data, at least oneperformance metric associated with the workflow. Determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully may be based on determining that the at least oneperformance metric associated with the workflow fails to satisfy atleast one threshold performance value.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by thefirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfigure the first microservice based ondetermining that the processing, by the first microservice, of thetransaction object did not complete successfully by generating aconfiguration transaction object that may be configured to causereconfiguration of the first microservice and adding the configurationtransaction object to the streaming data platform. The steps may furthercomprise causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully. Reconfiguring the first microservice may be basedon determining that the repeat processing of the transaction objectfailed. Reconfiguring the first microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to modify at least one operation that the firstmicroservice performs on transaction objects associated with theworkflow. Reconfiguring the first microservice may comprisereconfiguring a related second microservice to cause the removal of thefirst microservice from the workflow. The second related microservicemay be a predecessor microservice that proceeds the first microservicein the workflow. The steps may further comprise determining, by thewatchdog microservice, at least one performance metric associated withthe first micro service. Determining that the processing, by the firstmicroservice, of the transaction object did not complete successfullymay be based on determining that the at least one performance metricassociated with the first microservice fails to satisfy at least onethreshold performance value. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the workflow. Determiningthat the processing, by the first microservice, of the transactionobject did not complete successfully may be based on determining thatthe at least one performance metric associated with the workflow failsto satisfy at least one threshold performance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully; and reconfiguring the first microservice or arelated second microservice, based on determining that the repeatprocessing of the transaction object also did not complete successfully.Reconfiguring the first microservice may comprise generating aconfiguration transaction object that may be configured to causereconfiguration of the first workflow by causing reconfiguration of thefirst microservice. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow, and acurrent workflow stage of the configuration transaction object.Reconfiguring the first microservice may further comprise adding theconfiguration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Reconfiguring the first microservice or the related second microservicemay cause transaction objects associated with the workflow to bedynamically re-routed.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

1. A computer-implemented method comprising: receiving a transactionobject comprising transaction details and transaction metadata, whereinthe transaction metadata comprises: an indication of a workflowcorresponding to a transaction type of the transaction object, whereinthe workflow corresponding to the transaction type comprises a pluralityof processing steps required to validate a given transaction of thetransaction type; and a current workflow stage of the transactionobject; adding the transaction object to a streaming data platform;polling, by a first microservice, the streaming data platform toretrieve transaction objects matching a first workflow stage, whereinthe first workflow stage is associated with the first microservice basedon the workflow corresponding to the transaction type; processing, bythe first microservice, the transaction object based on the currentworkflow stage matching the first workflow stage; updating the currentworkflow stage of the transaction object to a second workflow stagebased on completing processing, by the first microservice, of thetransaction object; and polling, by a watchdog microservice, thestreaming data platform to retrieve transaction objects having a changedcurrent workflow stage; in response to determining, by the watchdogmicroservice, that the current workflow stage of the transaction objecthas changed, storing workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice, that the processing, by the firstmicroservice, of the transaction object did not complete successfully;and causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice.
 2. The method ofclaim 1, further comprising: polling, by the snapshot microservice, thestreaming data platform to retrieve transactions matching aninitialization stage, wherein transactions are added to the streamingdata platform in the initialization stage, and wherein theinitialization stage is associated with the snapshot microservice;retrieving, by the snapshot microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with addenda data of thetransaction object has changed after the transaction object has left theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data.
 3. The method of claim 2, wherein the snapshotmicroservice causes the first microservice to repeat processing of thetransaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice.
 4. The method of claim 1, wherein causing the firstmicroservice to repeat processing of the transaction object comprises:regenerating, by the snapshot microservice, the transaction object basedon snapshot data corresponding to the transaction object from prior tothe start of the processing by the first microservice; and returning theregenerated transaction object to the streaming data platform, whereinthe current workflow stage of the regenerated transaction object is setto the first workflow stage.
 5. The method of claim 1, furthercomprising: determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe first microservice, wherein determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully is based on determining that the at least one performancemetric associated with the first microservice fails to satisfy at leastone performance threshold value.
 6. The method of claim 5, wherein theat least one performance metric corresponds to a single transactionobject.
 7. The method of claim 5, wherein the at least one performancemetric corresponds to a group of transaction objects over a period oftime.
 8. The method of claim 1, further comprising: determining, by thewatchdog microservice and based on the workflow tracking data, at leastone baseline metric associated with the first microservice, wherein thebaseline metric corresponds to processing performance by the firstmicroservice on a set of transaction objects over a period of time; anddetermining, by the watchdog microservice and based on the workflowtracking data, at least one performance metric associated with a firsttransaction object processed by the first microservice, whereindetermining that the processing, by the first microservice, of thetransaction object did not complete successfully is based on determiningthat the at least one performance metric associated with the firsttransaction object fails to satisfy a threshold relationship to the atleast one baseline metric.
 9. The method of claim 1, further comprising:determining a number of times that the transaction object has undergoneprocessing by the first microservice; in response to determining thatthe number of times that the transaction object has undergone processingby the first microservice exceeds a threshold value, rejecting thetransaction object as having failed processing associated with the firstmicroservice; and determining a corrective action for the transactionobject based on rejecting the transaction object.
 10. The method ofclaim 9, wherein the corrective action comprises re-routing the firsttransaction object to be processed by another microservice.
 11. Themethod of claim 9, wherein the corrective action comprises changing thetransaction type of the transaction object.
 12. The method of claim 9,wherein the corrective action comprises changing the indication of theworkflow corresponding to the transaction type of the transactionobject.
 13. The method of claim 9, further comprising: determining, bythe watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice; anddetermining, by the watchdog microservice, a value for use as thethreshold value based on the at least one performance metric.
 14. Atransaction exchange platform comprising: a streaming data platform; aplurality of microservices, wherein each microservice of the pluralityof microservices is configured to poll the streaming data platform toretrieve transaction objects in a corresponding workflow stage based ona plurality of workflows corresponding to a plurality of transactiontypes; at least one processor; and memory storing instructions that,when executed by the at least one processor, cause the transactionexchange platform to: receive a transaction object comprisingtransaction details, addenda data, and transaction metadata, wherein thetransaction metadata comprises: an indication of a workflowcorresponding to a transaction type of the transaction object, whereinthe workflow corresponding to the transaction type comprises a pluralityof processing steps required to validate a given transaction of thetransaction type; and a current workflow stage of the transactionobject; add the transaction object to a streaming data platform; poll,by a snapshot microservice, the streaming data platform to retrievetransactions matching an initialization stage, wherein transactions areadded to the streaming data platform in the initialization stage, andwherein the initialization stage is associated with the snapshotmicroservice; retrieve, by the snapshot microservice and from thestreaming data platform, the transaction object based on the currentworkflow stage matching the initialization stage; store, by the snapshotmicroservice, snapshot data corresponding to the transaction object;process, by a first microservice, the transaction object on thestreaming data platform based on the current workflow stage matching afirst workflow stage, wherein the first workflow stage is associatedwith the first microservice based on the workflow corresponding to thetransaction type; determine, by the snapshot microservice and via thestreaming data platform, that at least one value associated with theaddenda data of the transaction object has changed after the transactionobject has left the initialization stage; and store, by the snapshotmicroservice, snapshot data corresponding to the changed at least onevalue associated with the addenda data update the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, store workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determine, by the watchdog microservice, that the processing, bythe first microservice, of the transaction object did not completesuccessfully; and cause the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object captured by a snapshot microservice.
 15. Thetransaction exchange platform of claim 14, wherein the snapshotmicroservice causes the first microservice to repeat processing of thetransaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice.
 16. The transaction exchange platform of claim 14,wherein the instructions cause the transaction exchange platform tocause the first microservice to repeat processing of the transactionobject by causing the transaction exchange platform to: regenerate, bythe snapshot microservice, the transaction object based on snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice; and return the regeneratedtransaction object to the streaming data platform, wherein the currentworkflow stage of the regenerated transaction object is set to the firstworkflow stage.
 17. The transaction exchange platform of claim 14,wherein the instructions cause the transaction exchange platform todetermine that the processing, by the first microservice, of thetransaction object did not complete successfully by causing thetransaction exchange platform to: determine, by the watchdogmicroservice and based on the workflow tracking data, at least oneperformance metric associated with the first microservice; and determinethat the processing, by the first microservice, of the transactionobject did not complete successfully based on determining that the atleast one performance metric associated with the first microservicefails to satisfy at least one performance threshold value.
 18. Thetransaction exchange platform of claim 14, wherein the instructionsfurther cause the transaction exchange platform to: determine, by thewatchdog microservice and based on the workflow tracking data, at leastone baseline metric associated with the first microservice, wherein thebaseline metric corresponds to processing performance by the firstmicroservice on a set of transaction objects over a period of time;determine, by the watchdog microservice and based on the workflowtracking data, at least one performance metric associated with a firsttransaction object processed by the first microservice; and determinethat the processing, by the first microservice, of the transactionobject did not complete successfully based on determining that the atleast one performance metric associated with the first transactionobject fails to satisfy a threshold relationship to the at least onebaseline metric.
 19. The transaction exchange platform of claim 14,wherein the instructions further cause the transaction exchange platformto: determine a number of times that the transaction object hasundergone processing by the first microservice; in response todetermining that the number of times that the transaction object hasundergone processing by the first microservice exceeds a thresholdvalue, reject the transaction object as having failed processingassociated with the first microservice; and determine a correctiveaction for the transaction object based on rejecting the transactionobject.
 20. One or more non-transitory computer readable media storinginstructions that, when executed by at least one processor, cause atransaction exchange platform to perform steps comprising: receiving atransaction object comprising transaction details, addenda data, andtransaction metadata, wherein the transaction metadata comprises: anindication of a workflow corresponding to a transaction type of thetransaction object, wherein the workflow corresponding to thetransaction type comprises a plurality of processing steps required tovalidate a given transaction of the transaction type; and a currentworkflow stage of the transaction object; adding the transaction objectto a streaming data platform, wherein the transaction object is added tothe streaming data platform in an initialization stage; polling, by thesnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage, wherein theinitialization stage is associated with the snapshot microservice;retrieving, by the snapshot microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object;processing, by a first microservice, the transaction object on thestreaming data platform based on the current workflow stage matching afirst workflow stage, wherein the first microservice is configured topoll the streaming data platform to retrieve transaction objectsmatching the first workflow stage based on the workflow corresponding tothe transaction type; determining, by the snapshot microservice and viathe streaming data platform, that at least one value associated withaddenda data of the transaction object has changed after the transactionobject has left the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the changed at least onevalue associated with the addenda data; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; and in response to determining, by a watchdog microserviceconfigured to poll the streaming data platform to retrieve transactionobjects having a changed current workflow stage, that the currentworkflow stage of the transaction object has changed, storing workflowtracking data corresponding to the transaction object and the changedcurrent workflow stage; determining, by the watchdog microservice, thatthe processing, by the first microservice, of the transaction object didnot complete successfully; and causing the first microservice to repeatprocessing of the transaction object based on snapshot datacorresponding to the transaction object captured by a snapshotmicroservice by: regenerating, by the snapshot microservice, thetransaction object based on snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice; and returning the regenerated transaction object tothe streaming data platform, wherein the current workflow stage of theregenerated transaction object is set to the first workflow stage.